Histoire de dates

[lyaak]

bonjour

je suis revenue sur Atys il y a peu, et ai remarquer que la date du jour donné sur l'encyclopatys (en bas a gauche) n'est pas bonne. après recherches j'ai trouvé http://fondation.bourdu.org/time.htm
mais voilà je me pose des questions puisque la date donnée pour l'event de ce soir est le 20 pluvia-II alors que d'après le site on est au troisième cycle et non au second.

[edit] il semble en éffet qu'il y ai juste une petite erreur, l'event d'hier était bien au CA 3

[kervala]

De toute façon, personne n'a la date correcte estimée :s Le seul truc qui est sensé être bon, c'est la date du moment présent :)

[cedrigo]

Le petit soft de la fondation est assez fiable.

J'ai fait un test sur des événements lointains (2004) dont j'avais la date précise et des luciogrammes, et le convertisseur m'a donné la bonne année et la même saison que celle des lucios. Je doute qu'on puisse avoir une précision au jour près, mais la saison c'est déjà super.

A ce propos, si quelqu'un a conservé des screenshots du 20 sept 2004 (posté sur un forum ou autre) et qui indiquent la saison clairement, ça m'aiderait beaucoup pour un event futur (anniversaire). Etant dans les lacs à l'époque la saison n'est pas facile à identifier, alors si vous étiez en jungle ou forêt... ;)

Merci d'avance

[kervala]

Oui j'ai même viré le mien vu que celui de Prysma est mille fois mieux :)

Il tient compte de plusieurs dates passées pour avoir une conversion la plus précise possible.

[netto]

Oh un nid de kitin là !
*tousse* pardon je me suis perdu dans mes pensé... quel heure est il au juste ... oh 4e CA à ma montre ! mon dieu mon dieu elle est cassé ? *secoue la montre* bah c'est pas grave 2eme 3eme ou 4eme CA quel importance au final !

[houlecorn]

Oui le machin à Kotaro marche bien, c'est à dire au moins pour des dates pas trop éloignées de la date actuelle...
Ça repose - si je peux me permettre - sur une interpolation linéaire qui donne la date grâce au coefficient secondes atysiennes/secondes réelles (appelé BDT dans le script de Kotaro) et un repère facile (tick 0 <=> 30 Pluvia, 4e CA 2524, 00h00).

C'est à dire que ça marche bien, tant qu'on n'éteint pas le serveur, puisque les dates atysiennes évoluent paralèllement à son uptime.

Donc ce script ne marche pas sur de longues durées, plus particulièrement avant la reprise (oct 2008). Il faudrait donc au lieu d'une interpolation en établir plusieurs grâce à des dates repère, et sélectionner la bonne en fonction de la date choisie... Ce qui devrait donner un résultat acceptable en-dehors des périodes de serveurs éteints. Avec des données de dates précises comme repère, ça peut faire des très bons résultats.

En tout cas sans toute cette usine à gaz j'ai transformé un peu le script de Kotaro pour en faire des fonctions utilisables en PHP, histoire de pouvoir utiliser ça sur le site de tout un chacun, et ça donne ça :
http://lucjaulmes.free.fr/calendrier_php


Qui peut s'utiliser comme on veut...
<?php
include('calendrier.php');

function temps_restant_saison()
{
// On veut savoir le mois actuel (1 à 12)
$mois = atysdate('n');

// On en déduit le prochain changement de saison
while(++$mois % 3 != 1);
// NB le mois n°13 a bien un sens pour atystime

$changement = atystime(1,$mois);
$restant = $changement - time();

echo 'Il reste ',floor($restant/(24*3600)) ,'j ', floor(($restant/3600)%24),'h ',floor(($restant/60)%60),'m ',($restant%60),'s irl avant la prochaine saison ('.constant('SAISON_'.floor(($mois%12)/3)).').';
// exemple : Il reste 2j 0h 19m 50s irl avant la prochaine saison (Été).
}

$params = 'd,D,j,l,S,w,z,F,m,M,n,t,C,k,K,Y,y,a,A,g,G,h,H,i,s ';
$test = array_combine( explode(',',$params), explode(',',atysdate($params)) );
echo '<p>On est à cet instant le ' .$test['l'],', ',$test['F'],' ',$test['j'], ', ', $test['C'], 'e CA ', $test['Y'], ', il est ', $test['H'], ':', $test['i'], ':', $test['s'], ' et la saison est le ',$test['K'],'.</p>';
// exemple : On est à cet instant le Holeth, Germinally 18, 2e CA 2545, il est 10:11:46 et la saison est le Printemps.
?>

[houlecorn]

Voilà, j'ai corrigé un peu http://lucjaulmes.free.fr/calendrier_php et en ajoutant à côté http://lucjaulmes.free.fr/goodtimes_php on obtient des dates correctes dans le passé.

[netto]

En effet le problème viens du faite que lorsque le serveur est arrêté, le temps IG (Tick) est lui aussi arrêté alors que le temps IRL, lui, continue de s'écouler. Ceci provoque alors un glissement des couples dates IRL/IG passés lors du calcule.

Exemple (non concret) :
imaginons que le "16 janvier 2009" corresponde au "16 Thermis 3eme CA 2547"
Si le serveur de redémarre pas depuis cette date, le calcule linéaire devrait donner le même résultat.
Mais si le serveur a eu 1 journée d'arrêt le 1 mars par exemple, le glissement des dates donnera alors un décalage d'une journée IRL lors du recalcule de la date passé. Soit "17 janvier 2009" = "16 Thermis 3eme CA 2547"

C'est en effet le point faible. Malheureusement ce glissement entre les dates IRL/IG n'est pas calculable linéairement. Pour cela il aurait fallu prendre en compte tout les dates d'arrêts du serveurs ainsi que leurs durée depuis le lancement. Sans compter qu'il faudrait remettre le programme à jour à chaque nouvelle arrêt du serveur (et ca c'est vraiment trop contraignant).

Une autre methode consisterai a créer dynamiquement une base de donnée avec une référence date IRL/IG journalière afin de limiter de beaucoup le défaut de recalcule. Mais pour cela il faudrait une base central sur un serveur (ce qui n'était pas possible en Vbscript). Mais même ainsi, ceci ne serait vraiment efficace qu'a partir de sa mise en production. Reste que pour les dates passées cela resterait toujours aléatoire puisque les couples de dates de référence IRL/IG n'existent pas pour chaque jour écoulé avant la mise en production du système de référencement journalier.

Enfin bref, beau travail pour la convertion en PHP :)

[houlecorn]

Il explique bien le Tryker... De toute façon la solution la plus simple est de prendre comme convention que tout le monde arrête sa montre quand le serveur est down. Comme ça le temps réel et le temps atysien adhèrent comme il faut.

Sinon, en notant régulièrement dans les données du goodtimes le coupe date irl/ig (ce qu'on pourrait faire automatiquement toutes les n synchros par exemple) on obtiendrait des valeurs très exactes de dates à intervalles réguliers... donc des approximations plutôt raisonnables pour les glissement de dates.

[ulukyn]

Pourquoi ne pas recupe le tick serveur des logs et l'envoyé via une requete a un site web?

Ce qui permettrai de mettre à jour regulierement les couples dates ig/irl.

[netto]

Effectivement pour remonter le couple date IRL/IG (ou pourquoi pas le couple IRL/Tick cela revient un peu au même) on peu penser qu'il suffit de laisser tourner un ryzom en permanence afin de pouvoir analyser le log.

Malheureusement le Tick est un animal capricieux qui ne veux pas se monter si facilement. Il apparait par exemple dans les cas suivants :
- au demarrage (c'est pas le plus fiable d'ailleurs).
- lors du changement de region.
- lors du passage d'un vortex.
Autrement dit si vous restez sur place à rien faire, le Tick peu très bien ne pas avoir envie de se montrer du tout.

Ceci implique que seul les joueurs actifs peuvent faire la remonté de l'information vers le serveur. Ce qui nécessite le developpement d'un petit module local qui se chargera de remonter l'information à distribuer à plusieurs joueur volontaire.

[vl]

Bonjour,

Pour faire simple, j'ai codé pour vous une API pour accéder via Internet au tick des serveurs de jeux. C'est mis à jour toutes les minutes.

Tick sur Aniro: http://atys.ryzom.com/servertick/index.php?shardid=ani
Tick sur Arispotle: http://atys.ryzom.com/servertick/index.php?shardid=ari
Tick sur Leanon: http://atys.ryzom.com/servertick/index.php?shardid=lea

Vianney 'vl' Lecroart
CTO Ryzom

[faro1]

Si ca c'est pas la classe ...

Un grand merci VL :)

Lurtz

[nanaruto]

j'adore :) j'y comprend rien mais j'adore essayer de vous déchiffrer :p

[netto]

Bonjour,

Pour faire simple, j'ai codé pour vous une API pour accéder via Internet au tick des serveurs de jeux. C'est mis à jour toutes les minutes.

Tick sur Aniro: http://atys.ryzom.com/servertick/index.php?shardid=ani
Tick sur Arispotle: http://atys.ryzom.com/servertick/index.php?shardid=ari
Tick sur Leanon: http://atys.ryzom.com/servertick/index.php?shardid=lea

Vianney 'vl' Lecroart
CTO Ryzom

Ooooh !!! c'est super ca ^^

C'est claire, il n'est pas possible de faire mieux avec les logs dont nous disposions jusqu'alors. Et bien sur cela va rendre du coup inutile d'avoir un client ryzom qui tourne pour pouvoir calculer l'heure d'atys. Cela ouvre des perspectives interessantes.

Un grand merci. Je vais regarder comment utiliser cela.


---------------------------------------------------------------------------
EDIT :
c'est bon j'ai trouvé le truc qui marche pour exploiter le tick publié sur le site http://atys.ryzom.com/servertick pour mon script en VBS/HTA :

Function WebTick()
Dim IE, Page
Set IE = CreateObject("InternetExplorer.Application")
IE.Navigate "http://atys.ryzom.com/servertick/index.php?shardid=ani"
While IE.Busy
sleep = 100
Wend
Page = IE.Document.Body.InnerHTML
IE.Quit
Set IE = Nothing
WebTick=Page
End Function

Ensuite j'obtiens une valeur numerique contenant le Tick en appelant cette fonction. Donc il reste plus qu'a voir comment adapter le traitement de cette info dans mon horloge.

[houlecorn]

Ah vi c'est super chouette ça, merci VL !

J'ai repris tout ce que j'avais fait un peu différemment du coup, et ça donne la version 2 de la librairie atysdate. (http://lucjaulmes.free.fr/source.php?page=calendrier_v2.php&numerotation=on)
On peut toujours l'utiliser tel quel, la date actuelle et les dates théoriques futures se déduisant du tick grâce à l'API de VL. Pour le passé, et c'est optionnel, on peut configurer une base de données (e.g. mysql), ce qui donnera des résultas plutôt convaincants.
Le tout est servi avec quelques dates repères du passé soigneusement piquées et corrigées (pour les 3 dernières) à la fondation bourdu.

Edith : petite mise à jour. Même une démo pour faire le kéké (http://lucjaulmes.free.fr/dates.php).
Edith bis: Sgrunt, PHP 4 chez free, j'avais oublié... -_-

[houlecorn]

D'ailleurs tant qu'on y est, j'ai vu que l'API renvoyait Erreur 3 quand le shardid correspondait pas à un serveur, et 2 quand il était vide... Excusez ma curiosité, mais Erreur 1 c'est quoi, le serveur est down ? Et y en a d'autres ? :p

[zergus]

On est en 2009 *sort*

Lokido Duo-Fuong

[vl]

Petite amélioration, on peut passer en parametre le format:

f=0 : tick
f=1 : homine
f=2 : xml

par exemple:

http://atys.ryzom.com/servertick/index.php?shardid=ani&f=1

Faite chauffer vos développeurs web, d'autres API pourraient bientot arriver.

[haldahir]

Hey ! merci tout le monde :)

[netto]

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".

[kervala]

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

[netto]

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

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

Désolé VL

[houlecorn]

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.

[netto]

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). (ftp://kotaro.dnsdojo.com/export/logiciel/TimerV2.6.hta)
Power menu (qui n'est pas de moi :b) permet de maintenir cette fenêtre au premier plan :
- Power menu (ftp://kotaro.dnsdojo.com/export/logiciel/PowerMenu.zip)
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é.

[houlecorn]

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. :p) Ç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. :p

[netto]

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. :p) Ç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.

... 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.

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 ;)

[lyaak]

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

[houlecorn]

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 (http://lucjaulmes.free.fr/source.php?page=calendrier_php&numerotation=on) et éventuellement goodtimes.php (http://lucjaulmes.free.fr/source.php?page=goodtimes_php&numerotation=on)) et si il ne vous gène pas, la version 2 vous épargne le mal de se soucier des logs ! (calendrier_v2.php (http://lucjaulmes.free.fr/source.php?page=calendrier_v2.php&numerotation=on))

[kervala]

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.

[houlecorn]

Bof, ça se décale pas si vite que ça. Si tu joues une fois par semaine et que tu te sers de ce log là... ça devrait être largement suffisant. Ça force un peu à maintenir son serveur à jour, en même temps si on est à 20 minutes ig près sur les dates, c'est qu'on doit être plutôt actif dans le jeu non ? :p

[kervala]

Ben, c'est toi qui parlait d'un décallage du site par rapport aux logs :s

[netto]

Mouaip, mais sans un script PHP c'est pas aussi facile à faire...
C'est un compliment ?
Je dis ca car c'est exactemment ce que j'ai fais avec mon script :D. Si tu renomme l'extension .HTA en .HTML tu aura une belle page web sous Internet Explorer ("HTA" ca veux dire "HTML Application").

Pour le moment je vais pas me relancer dans du développement car mon PC principale a rendu l'âme et je dois m'occuper de sa sépulture et de son remplacement. Mais j'ai réalisé lors de vos derniers échanges que je devrai peut être m'orienter vers un mode hybride entre la version 2.5 et 2.6 de mon horloge pour béneficier de leur avantages respectif.

[eanne]

et voila, tu laise un chercheur 30 seconde tout seul et tout de suite il va vouloir faire de l'OGM avec tout et n'importe quoi ^^

La prochaine étape c'est greffer des pince de clopper sur le dos d'un yubo, vous allez-voir! :)

[houlecorn]

C'est un compliment ?
Dans ! Pas sans. Faute de frappe, mea culpa. ;)
Enfin je veux bien te complimenter hein, c'est pas le souci. :p


Ceci dit, dans une page PHP tu veux faire un appel à ta fonction et pouf c'est tout, tu peux afficher la date ig de ton évènement sur ton beau petit fan site de Ryzom, ou ton forum de guilde, etc. =D
J'ai pas forcément envie de mettre à jour le calcul toutes les 500ms comme tu fais, et donc je dispose pas des informations des minutes passées quand j'appelle ma fonction. Donc je ne peux pas calculer de base de temps à partir des ticks de l'API pour voir si j'ai décalage ou pas. Le mode hybride semble assez dur. Si je veux des bases de temps, j'ai besoin des logs.
Mais personnellement je suis pas à 1 minute irl près, comme ça on se débarasse des logs. :)

Xiom : le décalage dont on parlait est une erreur de calcul de la date de l'API de VL qui considère que l'année 2525 commence au tick 0 alors qu'elle commence un peu plus tard.
Il n'y a pas de décalage de calcul entre les ticks de l'API et les ticks des logs, mais dans le résultat du calcul à partir de ce même tick. Les dates de VL ne collent pas : on est selon lui en Winderly (donc printemps) et selon les autres en Mystia (hiver). Si tu lances ton jeu, tu verras qu'on est en hiver. :p

Edit : Si tu veux parler du décalage des dates de la fondation Mac Vea-O'Fyler, Le décalage était beaucoup plus grand (de l'ordre de 2 CA et pas 2 mois), j'avais recalculé à partir des ticks actuels les dates théoriques de ces moments là et pris comme correspondance ig/irl la date irl donnée et le changement de saison le plus proche de la date théorique. Le raisonnement peut-être faux, je veux dire que je peux avoir dans ces 3 dates une saison (3 mois) d'avance sur ce qu'étaient les dates à l'époque.

10/8/2008 2:19:00 => date relevée = 1 Winderly IV 2541 ; date théorique = 5 Floris I 2542 ; changement de saison le plus proche = 1 Floris I 2542
28/8/2008 3:10:00 => date relevée = 1 Winderly I 2542 ; date théorique = 27 Folially II 2542 ; changement de saison le plus proche = 1 Floris II 2542
19/9/2008 14:44:00 => date relevée = 1 Floris II 2542 ; date théorique = 18 Thermis III 2542 ; changement de saison le plus proche = 1 Harvestor III 2542

[netto]

Ceci dit, dans une page PHP tu veux faire un appel à ta fonction et pouf c'est tout, tu peux afficher la date ig de ton évènement sur ton beau petit fan site de Ryzom, ou ton forum de guilde, etc. =D ...


Je pense qu'il faut utiliser le bon produit pour le bonne usage. Je ne pense pas qu'un programme tournant localement sur un PC (comme mon horloge) puisse être bon dans la convertion de date (c'est pour cela que je n'insiste pas la dessu). De même je ne pense pas qu'un site web en PHP puisse être bon dans l'affichage en temps réels. Par contre l'inverse est totalement vrai, un programme tournant en local doit être bon dans l'affichage en temps réel de l'heure, et un site web doit être bon dans la convertion de date. Donc ceci impliquer que nos préoccupations ne sont pas forcement identique sur tout les points.

Ceci dit ce que tu a fait en PHP est remarquable !



Xiom : le décalage dont on parlait est une erreur de calcul de la date de l'API de VL qui considère que l'année 2525 commence au tick 0 alors qu'elle commence un peu plus tard.
Il n'y a pas de décalage de calcul entre les ticks de l'API et les ticks des logs, mais dans le résultat du calcul à partir de ce même tick. Les dates de VL ne collent pas : on est selon lui en Winderly (donc printemps) et selon les autres en Mystia (hiver). Si tu lances ton jeu, tu verras qu'on est en hiver. :p


Moi je dit bien les deux choses :
- oui il y a un décalage évident dans la traduction en date IG dans l'API VL. Ce qui est une erreur regrettable.
- oui il y a bien une incertitude* aboutissant à un décalage aléatoire lors des calcules dans les ticks avec l'API. Ceci doit malgré tout pouvoir être corrigé avec un peu plus de travail. Mais, une fois de plus, je suis concerné par ce problème car je fais de l'affichage en temps réelle. Cela ne devrai pas vraiment concerner les gens qui exploitent l'API pour leur site web.

*Et la je dis bien "incertitude" et non "erreur". L'API fait très bien son boulot sur la publication du tick.

[kervala]

J'ai l'impression que le bug des 2 mois et 1 jour est corrigé dans l'API :)

[eanne]

dites moi :)

par hasare votre API, quand vous la faîte tournée, vous envoyez une question (la date?) pour recevoir une réponse? (il est telle heure tel jour)

essayez sans envoyer de question, mais de recevoir la date en continu, la "question" aura pour réponse l'heure reçu du serveur sans "attente" :)

[houlecorn]

Oui, le calcul de l'API de VL semble corrigé. Du moins il colle avec nos valeurs, et donc avec les saisons ig. :)


J'ai remis un peu à jour atysdate (http://lucjaulmes.free.fr/source.php?page=calendrier_v2.php&numerotation=on). Ça devrait être parfaitement fonctionnel maintenant, pour des dates dans le passé comme dans le présent, à 20 minutes près. Dans le futur aussi, sous réserve que le serveur se casse pas la gueule. :p Si des premiers utilisateurs veulent s'aventurer, tenez moi au courant.

Eanne, j'ai pas tout compris. L'API c'est la page de VL qui donne le tick (http://atys.ryzom.com/servertick/index.php?shardid=ani). C'est juste une page. On lui demande rien, elle nous donne un tick dont on sait seulement qu'il date de moins d'une minute.

[eanne]

autant pour moi :p

[lyaak]

j'ai un petit souci pour créé la base de donnée :(


Erreur

requête SQL:

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"

MySQL a répondu: Documentation
#1193 - Variable système ' 00000000000000000000000000000000000000000000000000 00000000826816nconnue

[houlecorn]

C'est apparemment une erreur dûe au fait que les versions de MySQL sont pas les mêmes... Essaye de supprimer la ligne " SET SQL_MODE=”NO_AUTO_VALUE_ON_ZERO”; " et éventuellement aussi "ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci" si ce passage cause une deuxième erreur.

Le code pour créer la table devient donc :
CREATE TABLE `reperes_ani` (

`irl` bigint(20) unsigned NOT NULL,

`ig` bigint(20) unsigned NOT NULL,

PRIMARY KEY (`irl`),

KEY `ig` (`ig`)

) ;

Ça devrait pas poser de problèmes pour ce qu'on fait de la base de données. L'insertion des valeurs reste identique.

[lyaak]

merci je vais essayer ça