Je ne suis pas expert en informatique, mais cela représente t-il un si grand travail que de programmer des sauvegardes plus fréquentes afin d'éviter des rollback de plus de 10 minutes? J'ai joué sur plusieurs autres et serveurs et celui-ci est bien le seul à perdre autant d'informations suite à un crash. A la longue on perds un bon nombre d'heures de jeu juste à cause des données perdues suite à un crash. Depuis le temps que je suis sur le serveur les gens se plaignent de ces rollback anormalement longs donc serait-il possible d'augmenter la fréquence de sauvegarde du serveur pour éviter ce genre de désagréments qui sont nuisibles à la bonne humeur des joueurs?

Je ne peux qu'approuver en ayant perdu 4 patrons forge 365 après avoir up 360-365 hier soir pendant le crash, sans compter certains compo ... Je me suis dit :" ça ne peut pas crash 2 fois en 2h, et bien si..."
Cela devient usant à la longue, il faudrait screen toutes les 5min et faire un .save ou ALT+F4 à chaque fois que l'on fait quelque chose de décisif.
Je pense que cela entrave grandement l'expérience de jeu et le "plaisirs" de farmer...
Je pipe rien au codage et à l'informatique, mais je pense qu'il y a des solutions.
Bref j'espère que cela ne sera pas un dialogue de sourd.
Amicalement
Tychios

Edit: D’ailleurs je ne comprend pas pourquoi après un rollback, certains compo / loot / item de quête, sont sauvegardé et pas d'autre ??

Pensez au "/s .save" à la fin de vos macro et les rollback ne seront qu'un lointain souvenir :)

Pensez au "/s .save" à la fin de vos macro et les rollback ne seront qu'un lointain souvenir :)

C'est ce que je pensais aussi mais il y a un cd sur le .save donc il vaut mieux se faire une macro à part et l'utiliser au bon moment.

si vous aimez vous accommoder du bricolage alors vous êtes pas trop difficiles enfin si çà gène pas les gens tant que çà

[Viou]

Si c'est faisable au niveau technique, pourquoi pas j'ai envie de dire. Après tout, ça arrangerait tout le monde.
Toutefois, je ne peux m'empêcher de penser que d'autres facteurs doivent entrer en compte, sinon depuis le temps et le nombre de plaintes, ça aurait déjà été fait j'imagine.
A défaut de pouvoir régler directement le problème du rollback à la source, je rebondirais bien sur ce qu'a dit Aeleana, à savoir ce fameux cd de .save, en réduisant par exemple le CD. Si on peut .save de façon plus régulière, ça peut parfois éviter les ratés et servir de solution de dépannage plus fiable (peut-être).

Oui mais non justement. Si tu diminue le cd du .save, cela apportera les même problèmes que de diminuer le cd de la sauvegarde automatique vu qu'il y a bon nombre de personnes qui mettent justement ce .save en macro.
Comme tu l'as dit, si la solution était évidente, il y a longtemps que le problème serait réglé. Pour le moment on ne peut se débrouiller qu'avec les outils à notre disposition.

[Viou]

Oui mais non justement. Si tu diminue le cd du .save, cela apportera les même problèmes que de diminuer le cd de la sauvegarde automatique vu qu'il y a bon nombre de personnes qui mettent justement ce .save en macro.
Comme tu l'as dit, si la solution était évidente, il y a longtemps que le problème serait réglé. Pour le moment on ne peut se débrouiller qu'avec les outils à notre disposition.

Ah, je vois ce que tu veux dire, j'avais pas envisagé ça sous cet angle avec le .save

Sur un sujet légèrement différent :
viewtopic.php?f=15&t=35646

L'une des limites actuellement c'est trouver un système qui ne génère pas une quantité monstrueuse de données.

C'est le même problème ici je pense.

Je suppose que la limite viens de l'hébergeur des machines et/ou de l'aspect financier?

[Viou]

Je suppose que la limite viens de l'hébergeur des machines et/ou de l'aspect financier?

Fort probable que ce soit ça en effet.

Cela est largement faisable , juste une variable ou un paramètre a changer dans la config , mais j'imagine qu'une sauvegarde doit être lourd au niveau du serveur ce qui explique que le timer est si long

Le jeu tourne en temps réel mais vous ne pouvez pas écrire dans la base de données en temps réel (en tout cas en SQL), donc il y a certains checkpoints (échange, déco, .save...) pour sauvegarder régulièrement votre progression.

Le sujet est déjà abordé ici : viewtopic.php?f=15&t=35646

oui, on parle de la fréquence de ces checkpoints à la base mais il semble que la facture de stockage de données soit trop élevée pour améliorer çà =)

http://forum.paragon-servers.com/showthread.php?tid=17740&pid=178698#pid178698

Cey de la bombe, après je sais pas si j'ai le droit de cité un autre serveur, mais implanté ce système... ça serait le rêve x)

Le système anti-crash rattrape les divers signaux de crash (à savoir : SIGSEGV, SIGILL et SIGABRT). Le gestionnaire de signal détecte l'instance (Map et ID d'instance) fautive, réalise une sauvegarde d'urgence en DB, puis élimine tous les éléments de cette instance (mobs, joueurs, etc.). Lorsque les joueurs se reconnectent, l'instance est rechargée à partir de la DB.

Enory tu sais lire? :0 ! non plus sérieusement si on a ce système ça serait top ! ça vend du rêve x)