Question de date

[asharan]

Bon le premier ou la première qui me file un programme qui affiche la date dans ryzom.. Bin je veux bien l'aider à pexer en le healant gratos

Vu que nevrax est occupé sur le ring

[jenbat]

A mon tour, comme j'ai du temps libre, et grace aux informations récupérées sur ce thread, je viens de coder une petite horloge.

Le projet "visual C++ 2005 express", avec les source et le binaire compilé est accessible ici :

http://dl-3.free.fr/52616e646f6d49562c3 ... sClock.zip

Je me base sur les informations trouvées dans log.log de Ryzom (a condition d'avoir installé dans le répertoire par défaut), pour calculer la date et l'heure Atysienne courante.

Bizarement, je trouve un décalage d'exactement 2 mois Atysien (72h IRL) par rapport au changement de saisons. Donc j'ai ajouté un dialogue pour configurer un décalage (cycle/mois/jour) par rapport au ServerTicks
Et un coefficient pour le calcul entre 2 mise a jour du log, correspondant au nombre de Tick en 100 secondes (1000 en théorie, 988 semble donner une approximation très correcte ce matin).

PS : Ca n'est pas un affichage "dans Ryzom", mais "au dessus de Ryzom" .

PPS : Si quelqu'un trouve pourquoi j'ai 2 mois de décalage, je suis preneur ...

PPPS : Il faut avoir lancé Ryzom au moins une fois pour que ça marche (sinon y'a pas de log) mais je pense pas que ca soit un gros problème...

[selyana]

Bizarement, je trouve un décalage d'exactement 2 mois Atysien (72h IRL)

étrangement j'ai un décalage de 40 jours IG (48h IRL) avec mon calcul à moi


(EDIT: après re-calcul et avalement des pilules bleus, c'est bien 60 jours comme toi : ne jamais faire de calcul le matin au réveil )

[kervala]

Alors tout d'abord, merci pour vos analyses

Je pense qu'on a bien avancé ^^

Moi j'ai ça dans mon log :

// 2006/08/25 00:45:29 ...
// 585762821 42465682282 - _CurrentReceivedNumber=125 _CurrentServerTick=585763071

// 2006/08/25 00:46:36 ...
// 585762943 42465749982 - _CurrentReceivedNumber=399 _CurrentServerTick=585763741

C'est pratique car on a l'heure à la seconde près qui est affichée au début

Ensuite, j'ai remarqué que le nombre suivant était identique pendant toute la synchonisation donc elle doit représenter l'heure du début de la synchronisation (la valeur ressemble bcp au CurrentServerTick), le nombre suivant représente une durée en ms (dans mon exemple il s'est écoulé 67 secondes et la différence des 2 nombres fait 67700), CurrentReceivedNumber doit être le nombre de synchro qu'on a eu donc ça sert à rien Et enfin CurrentServerTick doit être une durée en dixième de secondes (la différence entre les 2 valeurs est 670 ^^).

Donc avec ça, j'essaie de calculer le nombre de secondes écoulées depuis le jour de le release en faisant : heure_courante - heure_de_synchro + (CurrentServerTick / 10)

heure_de_synchro, c'est la date tout au début de la ligne et je divise CurrentServerTick par 10 car c'est en dixième de secondes

Ce qui me donne :
Date IRL à transformer : 25/08/2006 à 12:59:57
Quarta, Fallenor 10, 2e CA 2534 (JY) à 12:45:0 (on est donc bien en automne par contre, c'est le dernier mois de la saison )

Donc j'ai également un décallage de 2 mois

Par contre, j'ai du mal à trouver à quelle durée correspond le nombre 42465749982 ça fait 491 jours alors que le CurrentServerTick fait 677 jours :s

[kervala]

D'après la version dynamique du script la changement de saison aurait eu lieu le 25/08/2006 à 02:36:16 donc ça va, il n'y a pas une grande marge d'erreur ^^

En fait, je vais devoir faire 2 versions une pour l'heure actuelle et une pour les calculs car je ne peux pas utiliser la version avec CurrentServerTick pour calculer une date passée

Par contre, pour le fait que la date commence le 16 octobre, il se pourrait que le code du serveur ait changé ce jour là (qu'il y ait un patch spécial ce jour-là ^^) et que donc l'heure ait été remise à zéro

Donc dans ce cas, il faudrait rajouter 2 mois IRL à cette date

Edit: 2 mois IRL à la date, ça fait trop donc c'est pas ça

[selyana]

Le projet "visual C++ 2005 express", avec les source et le binaire compilé est accessible ici :

PPS : Si quelqu'un trouve pourquoi j'ai 2 mois de décalage, je suis preneur ...
.

tu devrais mettre le chemin du fichier log.log dans ton fichier d'initialisation plutot que de le coder "en dur"

... et puis arrete de coder comme moi : salement avec des variables globales partout

pour les 2 mois de décalage je ne peux que constater que j'ai le même (après calcul sans touillette du café dans le clavier )

j'ai lu en diagonale, mais tu relis le fichier de config à tous tes ticks timer ? j'ai pas fais gaffe combien tu avais mis pour le timer, mais à mon avis une fois toutes les 5 minutes ça doit largement suffire.

je n'ai pas réussi à exécuter le prog ... sans doute parce qu'il ne trouve pas le fichier log.log vu que j'ai testé sur un autre PC que le PC de Ryzom

[selyana]

Et un coefficient pour le calcul entre 2 mise a jour du log, correspondant au nombre de Tick en 100 secondes (1000 en théorie, 988 semble donner une approximation très correcte ce matin).

987,5 pour moi; c'est pas mal en moyenne : tendance un poil lent le matin quand il n'y a personne, tendance trop rapide en début de soirée

[jenbat]

987,5 pour moi; c'est pas mal en moyenne : tendance un poil lent le matin quand il n'y a personne, tendance trop rapide en début de soirée

J'en suis resté aux valeurs entières , et comme ma petite horloge se resynchronise à chaque fois que _CurrentServerTick apparait dans le fichier de log, le décalage n'est pas grave

[kervala]

Bon, j'ai essayé 9.875 (987.5 / 100) au lieu de 10 et ça me donne 2 mois après le mois réel alors qu'avec 10 ça mettait 2 mois avant ^^

Voici le patch pour le fichier AtysClock.cpp (pour lire le chemin du fichier log.log dans le fichier de config ^^) :

Code: Select all

23a24
> char path[255];
39a41
> 		fscanf_s (iniFile, "LogPath = %s\n", path);
44c46
< 	RyzomLog = _fsopen ("c:\\program files\\ryzom\\log.log", "rt", _SH_DENYNO);
---
> 	RyzomLog = _fsopen (path, "rt", _SH_DENYNO);
61a64
> 		fprintf (iniFile, "LogPath = %s\n", path);

Donc on rajoute une variable globale : char path[255];

On rajoute : fscanf_s (iniFile, "LogPath = %s\n", path);
Après les autres fscan_s

On remplace le chemin en brut par "path"

Et on rajoute : fprintf (iniFile, "LogPath = %s\n", path);
Après les autres fprintf

Et dans le fichier AtysClock.cfg, on rajoute une ligne : LogPath = c:\program files\ryzom\log.log

J'ai pas beaucoup testé, mais ça semble marcher chez moi

Edit: j'avais oublié quelque chose

[netto]

changement de saison :
- 25 aout à 2h48 ou 4h02

j'étais là à 05h15min05 (0h00 IG) et c'était déjà l'automne qq minutes avant

j'étais là à 1h34min15s (0h00 IG) et c'était encore l'été

Maleureusement je ne peut pas me fier à l'heur réel pour caler l'horloge precisement mais mes estimations tournait autour de tes valeurs selyana.
Pour caler, je vais devoir relever ma date lors du changement IG de visu et regler le decalage jour/mois par rapport à cela (ou bien je peu regler par rapport à "1 date IG = ce Tick").

Je n'ai pas pu travailler dessu aujourd'hui mais je vous met la source on va dire en version beta ici pour ceux qui sont interessé par mes calcules

[EDIT Le lien etant devenu obsolette je l'ai supprimé. Voir le post suivant pour les sources]