Travaux perdus avec Profnsched

[Coethium]

Suite de la discussion engagée à a8a95a6

[Lymkwi]

Est-ce que tu peux clarifier ce qu'il faut faire? Le titre n'est pas assez explicite et le lien donne un code HTTP 404.

[BetterToAutomateTheWorld]

@LeMagnesium
J'ai corrigé le lien, le soucis est bien expliqué dans le lien, tu peux discuter ici de précision si tu en a besoin

[Coethium]

@LeMagnesium : le problème est que pour l'instant moi-même je ne sais ce qu'il faut faire car je n'ai pas pu reproduire le bug at home.

Le module mets les travaux en liste d'attente, puis les laisse s'exécuter progressivement en essayant de ne pas dépasser le tick-time du serveur. (il est donc normal que certains modules non prioritaires voient passer quelques steps entre leur différentes exécutions).

D'après le problème décrit, certains travaux viennent à disparaitre totalement de la liste d'attente, du coup ils ne sont plus jamais excécutés.

J'avais rencontré un problème similaire dans "queue.lua", fonction "scheduler.shift()" où un for/ipairs (ligne 45)ne prenait pas tous les éléments. En le remplaçant par un for/pairs le soucis avait été résolu. J'ai même laissé le code de débogage en fin de fonction, qui vérifie qu'aucun travail n'a été perdu.

Dans le nouveau bug, donc fortement ressemblant, le code de débogage ne s'est pas enclenché, j'en déduis que ce n'est pas cette fonction qui pose problème.

Il s'agit peut-être d'un autre couple for/ipairs, mais ceux restant ne me choquent pas : ils sont bien appliqués sur des listes triées (et surtout il est impératif que ces listes soient traitées dans l'ordre de tri, ce que ne garantierait pas un for/pairs)

[BetterToAutomateTheWorld]

On peut retenter en production en le réactivant, néanmoins il faudrait dans le meilleur des cas que tu sois là, que l'on puisse tester ensemble

[Coethium]

@Darcidride en mode kamikaze ? ^^
Avant de le faire, je rajouterai du code de débogage.

Après sans de suite tester en prod, ça peut aussi se faire sur l'une de vos machines sur laquelle on sait que le bug a été vu. Du moment qu'on est ensemble sur IRC ça doit être faisable sans trop de contrainte.

[ghost]

@Coethium Je testais les arbalètes pour trouver un bug et le bug est revenu, voila le log complet, j'ai regardé mais rien trouvé, j'ai fais la commande de dump aussi.
Y avait un lag de 0.2 quand je m'en suis aperçu, puis il est tombé a 0.1 vu qu'il exécutait moins de choses.
Bref tout ce que j'ai fait c'est recharger les arbalètes( qui utilisent des after).
Le sprint fonctionnait toujours, action_timers et itemdrop non.

http://zerobin.qbuissondebon.info/?add56299a93edfb8#tBKn5uNE3msEra5F+47gfeOe4EINDc3QfYwYiLeEH98=

[Coethium]

@Crabman77 merci ! Tu as lancé la commande de dump avant ou après avoir constaté le problème ?

La semaine prochaine je suis en vacances, donc je pourrai me pencher plus longuement dessus.

[ghost]

Je l'ai lancé après.

[Coethium]

Je bosse dessus, et je pense avoir trouvé le pb : en lua # ne renvoie pas le nombre d'éléments d'un tableau, mais le nombre d'éléments qui précèdent le premier élément nul. Forcément ça change tout...

[Coethium]

Voilà, j'ai corrigé les # que je juge problématiques.
Si l'un de vous peux tester sur sa machine ça serait cool. Sur la mienne je n'ai pas constaté de problèmes mais on sait que ce n'est pas représentatif (et j'ai testé 5mn de jeu environ).

L'idéal pour le débogage serait de lancer un /profnsched 0 avant les tests.

[ghost]

@Coethium je vient d'avoir à nouveau le bug.

[Coethium]

Hello ! Et bonne année :)
Y'a moyen d'avoir les log sur la période où ça a eu lieu ? Le log actuel débute à 8h30 ce matin.

Edit: en fait le problème vient certainement d'ailleurs car profnsched est désactivé dans le world.mt

[ghost]

Pas sur mon local et non pas de log.
J'ai fait plusieurs reboot pour tester mon code et connecter mon player plusieurs fois et ça me l'a fait une fois.