En regardant un retour de fight_get que m'a fourni Lark (http://pastebin.com/hbcy8Fbb), j'ai cherché à comprendre comment toutes les données étaient enregistrées. Je pense que les données "leeks", "team1" et "team2" sont assez claires. En revanche, il est difficile de comprendre directement comment sont organisées les données de "actions". Aussi,je n'ai pas bien compris "obstacles" de "maps" : on a les cellules où sont les obstacles, mais que représente le couple d'entier qui suit ?

Du coup j'ai créé une page sur le Wiki. Si vous avez compris des choses qui n'y figurent pas, n'hésitez pas à les ajouter. Ça devrait nous permettre de comprendre comment tout cela fonctionne. Plus tard, j'espère que nous pourrons lire les données du rapport directement dans le JSON.

• Restructuration de l'objet Leek() pour stocker les données overtime,
• restructuration de la fonction readActions(),
• appel d'une bibliothèque js pour tracer des graphes (j'ai pensé à Rickshaw),
• tracer un graph bien sympa, ou on pourra visualiser chaque donnée overtime pour chaque poireau,
• possibilité de cocher/décocher chaque poireau et chaque data.

Permettra, notamment en regardant la courbe de vie/dégâts, de voir rapidement si un combat était serré ou largement gagné, etc.

Suggestion sur le forum LeekWars :

Quid d'une ligne sous la ligne "total" de la section "résumé" d'une moyenne des totaux par leek ? J'avoue ne pas oser mettre les mains dedans...

J'ai construit la courbe d'équilibre pour montrer en temps réel qui mène le combat (sur la base des PV).
Pourtant, je ne suis que partiellement satisfait de cette formule :

( teams[0].life[current_turn] / teams[0].TotalLife - teams[1].life[current_turn] / teams[1].TotalLife ) * 100

Par exemple, sur ce combat, l'équipe PoirOdyssée gagne des PV sur les premiers tours du combat, grâce à Blindage. L'écart devrait donc se creuser avec l'équipe adverse, vu qu'on a plus de PV qu'au début du combat. Pourtant, la courbe fait l'inverse !

Avez-vous des idées/suggestions d'amélioration de cette courbe ?

Ce rapport de combat fait planter le kikimeter à la ligne 441:
currentFight.leeks[attacker] is undefined

Actuellement, les données overtime sont stockée de manière discrète : une pour chaque tour.
Pourtant, beaucoup de choses se passent durant un tour. On peut faire beaucoup de dégâts sur un full agi, qui se guéri juste après, lors du même tour. Dans ce cas, sa vie apparente n'a pas évolué à l'échelle du tour (ça se voit bien sur les graphes de Foudge).

La solution serait de stocker toutes les données avec un code temporel en virgule flottante.
Mettons qu'il y ait eu 20 actions (au sens du fichier JSON de fight_get) durant le tour n°4. La 14ème action aurait donc le code temporel 4+(14-1)/20=4.65.
Cette solution serait un peu plus lourde à gérer, mais tellement plus précise que je pense que ça vaut le coup.

Les INSERT ne se font plus dans la BDD. Correction en cours.

Je n'ai pas la maîtrise suffisante de la POO et de JavaScript, mais je pense qu'il serait bon de reprendre la structure des objets.
J'ai essayé, mais je n'ai pas vraiment réussi à faire ce que je voulais, donc j'ai abandonné.

ECMAScript5 permet des choses pas mal.
On pourrait avoir des beaux objets et leurs attributs/méthodes du genre :
currentFight.leek[name].dmg_out,
currentFight.FightId,
currentFight.leekCount,
currentFight.team[1].name,
currentFight.team[1].leekCount,
currentFight.leek[name].dmg_out.turn(4) : pour avoir les dommages subis jusqu'au tour 4,
et plein de fonctions pour calculer (et pas stocker) les données du genre TPperTurn, etc.

Cela permettra un code beaucoup plus propre et efficace. Notamment, pour les deux enhancement que je me suis assigné récemment. Sans cette amélioration des objets, j'arriverai à les faire, mais ça sera avec plein de fonctions toutes moches de partout.

Afficher une notification du type window.alert() avec le contenus des log d'erreur debugE().
Pas besoin de scroller toute la page pour voir si on as eu des logs d'erreur.
Ajout d'une option pour activer/désactiver cette fonctionnalité.

Actuellement les data "blabla" viennent fausser les pourcentages dans le tableau d'utilisation des PT.

La fonction readActions() plante quand elle parse la ligne 30 du combat ci-dessous.
Est-ce le B-Laser qui pose problème ?

http://leekwars.com/report/3479999

Dans le cas d'un combat contre soi-même, les fonctions du kikimeter ne fonctionnent pas correctement :
http://leekwars.com/garden/challenge=[ID de mon leek]
Pour corriger cela, il faudrait changer l'identifiant des poireaux dans l'objet leeks[name] par quelque chose d'unique.
leeks[name + hexcolor] ?
leeks[leekId] ?

C'est loin d'être prioritaire. Ça concerne un cas particulier et nécessiterai de changer beaucoup de code.

Permet de rapidement visualiser l'usage en armes&puces de chaque poireau.
Est-ce un full force ? full agi ? Quelles sont ses armes&puces préférées ? Combien de PT dépense-t-il ici ou là ? etc.

• Modifier l'objet Leek() pour accueillir les armes&puces utilisées par chaque leek et les PT associés,
• Ajouter quelques lignes de code dans readActions() pour parser les utilisations,
• Production d'un tableau : ligne : leek, colonne : armeoupuce, cellules : nombre de PT consommé.

Maintenant que les rapports de combats commencent à être pas mal complets, pourquoi ne pas s'attaquer à des statistiques plus globales ?
Je pense au suivi des stats majeures de nos leeks, farmer et team. Un graph sur la page de chaque poireau, du farmer et de l'équipe pour visualiser leur évolution au fil des jours.

Je propose ici un début de spec, n'hésitez pas à modifier ce commentaire.

Acquisition des données

Chaque jour, lors de la première connexion à leekwars.com, explorer - via ajax - les pages suivantes :

• http://leekwars.com/farmer ;
• les pages de chaque poireaux de l'éleveur connecté ;
• la page de l'équipe ;
• les pages de classement.

Ça fera peut-être un peu lourd en terme de temps d'exécution et de volume de data, mais vu que c'est la seule connexion de la journée et que c'est fait en tâche de fond, ça devrait aller sans problème.

Les données récupérées seraient structurées de la manière suivante :

[
    "datetime": value,    // Date et heure (plus précis que date seule)
    "data": {
        "farmer": {
            "id": value,    // id unique du farmer
            "talent": value,
            "fight_count": value,    // Nombre de combats réalisés
            "ratio": value,
            "trophy_count": value,
            "habs": value,
            "classement": value    // Classement du farmer à aller chercher dans http://leekwars.com/ranking/farmer
        },
        "leeks": [
            {
                "id": value,    // id unique du poireau
                "talent": value,
                "level": value,
                "fight_count": value, // Nombre de combats
                "ratio": value,
                "classement": value    // Classement du poireau à aller chercher dans http://leekwars.com/ranking
            },
            {
                ...
            },
        ],
        "team": {
            "id": value,    // id unique de l'équipe
            "level": value,
            "talent": value,
            "fight_count": value,
            "ratio": value,
            "classement": value    // Classement de l'équipe à aller chercher dans http://leekwars.com/ranking/team
        },
    }
],
[
    "datetime": value,
    "data":{}
]

Dans un premier temps, j'ai pensé qu'on pourrait laisser la possibilité à l'utilisateur de définir combien de jours garder en mémoire. Mais vu la faible quantité de données, tout garder ne devrait pas être un problème.

Avec JSON.stringify(), on peut stocker toutes ces données dans un seul GM_setValue() : simple et propre.

Pour gérer l'éventuel multi-compte sur la même machine, il faudrait donc stocker ces données dans un GM_setValue() contenant l'id du farmer connecté.

Récupérer ces données à la première connexion implique donc de modifier le @match du script pour tout le site leekwars.com et donc de contrôler via un if(document.URL == 'xxxx') l'exécution de chaque fonction du script.

Affichage des données

Sur la page de chaque poireau, du farmer et de l'équipe, insérer un graphique sur lequel on pourra visualiser chacune de ces données.
Des checkboxes ou radio_buttons seront donc disponibles, et on pourrait zoomer via un ascenseur horizontal.
Un peu comme ce qui est présenté ici.
Par défaut, le graph du classement sera affiché, zoomé sur les deux dernières semaine (pour ne pas flooder avec des vieilles données).