Dostuff

Un calculateur de stuff Dofus qui tourne hors ligne : décris ce que tu veux, il prouve le meilleur stuff possible - pas une bonne solution, l'optimum, avec le certificat mathématique qui va avec.

L'application aspire le catalogue des équipements et des sorts une seule fois depuis DofusDB, le range dans une base SQLite locale, et n'y retouche plus. Les 18 165 fichiers d'illustrations et de données de personnage sont embarqués dans le paquet : rien à extraire, rien à configurer. Au premier lancement, un écran d'accueil dit ce que le projet est - indépendant, non officiel - et à qui appartiennent DOFUS et ses contenus.

---

Table des matières

• Le calculateur
• Les dégâts
• Le stuff
• Le craft
• La rentabilité craft
• L'encyclopédie
• Les réglages
• Démarrer
• Les données
• Architecture
• Règles du dépôt
• Commandes
• Attributions

---

Le calculateur

La page calculateur cherche le meilleur stuff du catalogue selon tes critères, et le prouve.

• La requête : les statistiques à maximiser avec leurs poids - ou en ordre lexicographique - , des minimums durs (« PA ≥ 12, PM ≥ 6 »), le personnage (niveau, classe, parchotage, points figés ou optimisés par la recherche), et les hypothèses externes affichées, jamais silencieuses.
• La preuve : le moteur est un modèle en contraintes entières (CP-SAT) de tout le système d'équipement - paliers de panoplie exacts, anneaux de panoplie uniques, une prysmaradite, conditions évaluées sur la feuille finale, exclusivités entre items. Il ne rend jamais un résultat non prouvé : la meilleure solution et la borne supérieure se referment l'une sur l'autre, sans limite de temps, et cette fermeture - le statut OPTIMAL de CP-SAT - est la preuve. Le réglage bas niveau du moteur est mesuré, pas supposé : la campagne et son tableau vivent dans docs/research/fragments/solver-tuning.md, et une preuve typique tient sous la seconde sur une machine moderne pour une requête ordinaire. Avec la forge, une preuve qui demandait deux à huit minutes tient désormais en une dizaine de secondes : les requêtes qui forgent passent par la formulation compacte, mesurée de 17 à 50 fois plus rapide qu'elle sur les six scénarios de référence (docs/research/08-adaptive-formulations/results/2026-08-24/).
• La mémoire a un plafond, et c'est le seul rempart contre le noyau : une recherche trop lourde s'arrête au plafond et rend le meilleur build trouvé, non prouvé, au lieu de se faire tuer par l'arbitrage du système. Il se règle dans les Réglages ; laissé sur automatique il vaut ce que le système dit pouvoir prêter au moment du lancement, moins deux gibioctets laissés à la session. Le paramètre mémoire d'OR-Tools, lui, a été mesuré sans effet et n'est pas utilisé (docs/research/10-solver-memory/).
• Le dépassement est une perte, pas une invalidité : un stuff à 14 PA reste légal, le personnage en utilise 12 ; l'objectif compte les valeurs utilisables (plafonds 12 PA · 6 PM · 6 PO · 50 % de résistance par élément · 100 % de critique).
• Les substituts, sur autorisation : la Puissance peut compter pour les quatre élémentaires (le même point pour toutes à la fois, comme la formule de dégâts du jeu), les Dommages critiques et Pièges pour les lignes élémentaires. Chaque substitut affiche sa limite en permanence, le substitut compte dans la demande et jamais dans la feuille, et la carte des contraintes dit le détail (« atteint, dont 480 de Puissance »). Désactivé par défaut, réglable dans les Réglages.
• La forge et la transcendance, sur autorisation : le solveur peut choisir les jets et exotiques de la forgemagie normale, ou poser une rune de transcendance légale sur un objet. Les deux mécanismes sont exclusifs par objet, désactivés par défaut et détaillés position par position dans la preuve rendue. Une pastille T marque aussi chaque objet transcendé sur le plateau et en donne la rune au survol.
• Le résultat est un certificat : le chiffre prouvé au premier plan, ce qui a été maximisé à côté, et chaque demande en pastille - verte quand la réponse tombe exactement dessus, sourde quand elle laisse une marge. Le détail se déplie sur un registre qui met la demande en face de l'obtenu, ligne par ligne, avec le verbe de chacune : au moins 12 n'est pas maximiser ×3. Un arrêt au plafond mémoire ou une contradiction ont leur propre bande, ambre et rouge, et ne portent jamais le vocabulaire d'une preuve. Le résultat s'enregistre dans les stuffs ou s'ouvre sur la page Stuff, non enregistré.
• La feuille complète du build est à droite du plateau, pendant la recherche comme après, mise à jour à chaque solution trouvée ; sur une fenêtre étroite elle passe sous le plateau plutôt que de disparaître.
• Pendant la recherche, la page montre ce que fait la machine : le chronomètre à la milliseconde, une barre par cœur, la mémoire tenue avec son plafond marqué dessus, et les deux bornes tracées l'une contre l'autre - la meilleure solution qui monte, la borne qui descend, la bande entre les deux qui se referme. Sous elles, un couloir par stratégie du solveur : CP-SAT lance plusieurs algorithmes différents sur le même problème, et les couloirs disent lequel a trouvé la première solution, lequel tient la meilleure, et lequel a fini. Une recherche difficile peut rester muette plusieurs minutes : ces courbes, ces barres et ces couloirs sont la seule chose honnête qui dise qu'il se passe encore quelque chose.
• Les objets s'épinglent : un clic sur un emplacement du plateau ouvre le sélecteur, et l'objet choisi est imposé à cette position exacte. La recherche cherche le reste autour, et une position entièrement épinglée voit ses autres candidats retirés du modèle, ce qui accélère la preuve. Une épingle impossible rend la requête infaisable de façon prouvée, jamais une erreur.
• Annuler rend la meilleure solution en main, étiquetée non prouvée, jamais un timeout déguisé.

Les dégâts

La page dégâts estime ce que le build tape, arme par arme et sort par sort, avec un moteur exact pour les lignes et contextes qu'il sait représenter.

• La chaîne numérique représentée est reproduite au point près : dix troncatures dans l'ordre exact, et l'étage de la puissance calculé en virgule flottante 32 bits parce que c'est ce que fait le jeu. Un jet de 70 avec 760 de puissance rend 601, pas 602.
• Chaque ligne est une fourchette, en coup normal et en critique, avec l'espérance pondérée par le taux critique. Les dégâts fixes sont repliés dans chaque ligne élémentaire, parce que c'est là qu'ils tombent.
• Ce qui n'est pas un dégât n'est pas une ligne : dégâts directs, vols de vie, soins et dégâts de poussée sont calculés ; onze effets restent marqués non calculables plutôt que comptés à tort.
• Les variantes connues sont séparées, et deux lignes de la même école avec des jets différents sont des alternatives, jamais un cumul. Certaines conditions de ligne, zones par effet, limites par cible et progressions par lancer demandent encore une synchronisation plus riche avant de pouvoir servir d'objectif exact au solveur.
• La cible se décrit : résistances fixes et en pourcentage par élément, ou un préréglage.
• Les sorts d'objets (Dofus, objets légendaires, sorts déclenchés) sont là aussi.
• Le build se choisit dans la barre, au même sélecteur que la page craft : un champ de recherche épinglé au-dessus de la liste, qui ne défile pas avec elle. La page ne parle au milieu que dans un cas, quand aucun build n'est encore choisi.

Le stuff

La page stuff monte un personnage complet et dit ce qu'il vaut. Elle lit le même catalogue que l'encyclopédie et ne demande rien au réseau.

• Le plateau, en U, avec les seize emplacements du jeu. Un clic ouvre le sélecteur à la place du plateau ; les caractéristiques restent à gauche, puisque c'est contre elles qu'on juge un item.
• Le personnage au centre s'anime et porte le build. Un moteur de rendu local rejoue l'animation d'attente du jeu ; coiffe, cape et bouclier apparaissent sur le personnage, les cheveux disparaissent sous une coiffe, équiper une monture le met en selle, assis, sur le squelette que le jeu réserve aux cavaliers, et équiper un familier le lui met à ses pieds, à sa propre cadence. Validé au pixel contre le moteur du jeu, et hors ligne comme tout le reste. Ce que la conversion n'a pas su apparier - une poignée de familiers, les montiliers - laisse la figure telle quelle plutôt que de dessiner une créature au hasard.
• Le sélecteur filtre par nom, par fourchette de niveau, par sous-type - les treize types d'armes sont autant de vignettes en monochrome plutôt que treize mots - et par seuil sur n'importe quelle statistique. Les résultats se lisent en liste ou en cartes, et sont classés : d'abord ce qui porte le plus des statistiques exigées, puis le plus haut niveau.
• Les caractéristiques se répartissent au point près : parchotage et points achetés sont deux colonnes distinctes, les paliers de coût sont ceux du jeu, et une saisie trop grande retombe sur ce que le budget restant permet.
• La feuille est calculée entièrement - vie, PA, PM, portée, dommages par élément, résistances, dérivées - et signale en rouge ce qui dépasse un plafond utile : douze PA, six PM, six de portée, cinquante pour cent de résistance.
• La forgemagie, emplacement par emplacement. On édite le jet, pas un bonus : au-dessus du maximum du catalogue c'est un over, en dessous c'est simplement l'item qu'on possède. Les poids sont ceux du jeu, le budget de 101 est tenu au centième près, et les exotiques ont leur propre rang.
• La transcendance calculée reste attachée à l'objet : sa pastille T et sa fiche nomment la rune, et une sauvegarde conserve exactement la position, la statistique et le palier trouvés par le solveur.
• Les panoplies portées s'affichent sous le plateau avec le palier atteint, les pièces manquantes en grisé et ce que la pièce suivante ajouterait. Un clic droit sur une pièce propose d'équiper la panoplie entière d'un coup, en disant d'avance ce que ça remplacerait.
• Les stuffs se gardent, se rouvrent, se dupliquent. Ils sont écrits dans builds.json à côté du cache et ne stockent que des identifiants d'items, pour survivre à un catalogue vidé et refait.

Le craft

La page craft dit ce qu'il faut pour fabriquer un build enregistré : les métiers avec le niveau à atteindre, et la liste de courses.

• Le build se choisit en tête, dans un sélecteur qui cherche : accents, pluriels et mots dans le désordre indifférents, les lettres trouvées allumées, le clavier suffit.
• La bande des métiers, une ligne sous l'en-tête : icône, nom, niveau exigé (le plus haut que le build demande) et nombre d'objets ; un métier dont plus rien n'est retenu s'éteint au lieu de disparaître.
• Les objets à gauche, cochables : garder ou écarter chaque objet recalcule ingrédients et métiers. Tout, Aucun, et les objets sans recette restent listés avec la vraie raison : un Dofus vient de quête, une monture d'élevage.
• Les ingrédients à droite, agrégés : quantités sommées sur la sélection, chaque ressource disant son niveau et quels objets la réclament, triables par quantité ou par niveau.
• Les recettes viennent de la même synchronisation que le catalogue : environ 4 400 recettes d'équipement, leurs 2 957 ressources et les 23 métiers rejoignent le cache local, et toutes les icônes étaient déjà embarquées.

La rentabilité craft

La page Rentabilité craft, sous XP métier, compare les recettes d'un métier dans une tranche de niveaux inclusive. Elle réutilise le catalogue, les niveaux de métier relevés en jeu et les prix du serveur choisi.

• Quatre classements : coût d'achat, revente estimée, marge brute et rendement en pourcentage. Les prix inconnus restent inconnus ; un ingrédient manquant ne devient jamais gratuit.
• Le coût utilise les mêmes combinaisons de lots que XP métier, surplus acheté inclus. La revente est une estimation d'après les annonces ou, à défaut, le prix moyen marqué ≈ ; la marge est calculée avant taxes.
• La quantité à fabriquer dans le détail multiplie les besoins en ingrédients et affiche coût, revente et marge brute totaux. Les lots sont recalculés pour toute la quantité, sans multiplier le coût d'un craft ; le classement reste basé sur un craft.
• La fraîcheur est réglable, à un jour par défaut. Le détail d'une recette et la vue À relever indiquent les ressources et objets finis à consulter en HDV, sans doublons, avec ajout aux objets suivis.
• Les nouveaux relevés mettent le classement et les totaux à jour sans fermer la recette sélectionnée. Recettes craftables à mon niveau limite les recettes au niveau de métier connu ; Relevés HDV uniquement écarte les prix moyens.

L'encyclopédie

Elle couvre les 3 826 items équipables du jeu : amulettes, armes, anneaux, ceintures, bottes, coiffes, capes, boucliers, familiers, dofus et trophées, plus les 929 panoplies qui les regroupent.

• Recherche par nom, indifférente aux accents, au pluriel et à l'ordre des mots : epee trouve Épée Tulante, bottes trouve Botte de Sept Lieues, et bottes bouftou trouve Bottes du Bouftou.
• Filtre par emplacement, avec le choix du type précis là où il y en a plusieurs : 13 types d'armes, 5 de familiers, 3 pour les dofus et trophées. Chaque type affiche son nombre d'items.
• Filtre par caractéristique, sur les 52 statistiques réellement portées par un équipement, avec un seuil minimum par statistique. « Une cape, au moins 200 vitalité » se dit en deux clics.
• Fiche complète : dégâts de l'arme séparés des bonus qu'elle confère, effets libellés avec les mots exacts du jeu, conditions d'équipement lisibles, échelle des bonus de panoplie et texte d'ambiance.

Les items de maître de jeu, une douzaine aux statistiques hors d'atteinte, sont masqués par défaut, affichables, ou isolables. Le calculateur les écarte d'office.

Les réglages

Un engrenage dans la barre de titre ouvre une page de données, pas d'apparence : l'application est hors ligne par construction et il faut un endroit qui dise la vérité sur ce que la machine possède.

• Les données du jeu : nombre d'objets, date du dernier remplissage, version du jeu que les données décrivent, emplacement et poids du fichier, version de schéma, et l'installation de Dofus si elle est détectée. Une vérification de mise à jour interroge l'amont sur un clic, onze octets, sans rien télécharger. Une synchronisation qui échoue laisse les données locales intactes, et la page le dit.
• Le calculateur : ce qu'une requête neuve porte déjà. Stratégie, points figés ou optimisés, planchers de PA et de PM, hypothèses externes, nombre de recherches en parallèle. Le poids d'une statistique ajoutée à un objectif vient du prix que le forgeron lui donne ; les prix bruts s'étendant sur un facteur mille, la lecture adoucie est celle par défaut.
• Avancé : participation aux statistiques anonymes, réinitialisation, revoir l'écran d'accueil, le chemin du journal, et ce sur quoi l'application tourne, utile dans un rapport de bug. Une recherche qui échoue y écrit sa trace complète et la forme de la requête, là où l'écran ne montre qu'une phrase ; le fichier tourne et reste borné.

Démarrer

Installer - prends l'installeur ou la version portable pour Windows ou Linux sur dostuff.vyxs.fr, qui détecte ton système et montre le journal des versions ; les paquets Linux sont aussi attachés aux releases Forgejo. Rien d'autre n'est requis : le runtime Java et les illustrations sont dans le paquet.

Depuis les sources - il faut un JDK 17+ sur le PATH pour amorcer Gradle, qui télécharge ensuite tout seul la JetBrains Runtime 25 sur laquelle le projet compile.

./gradlew run

Au premier lancement l'encyclopédie est vide : un bouton récupère les items et les sorts depuis DofusDB. Les calculs et le catalogue restent locaux. La synchronisation du catalogue est volontaire ; le logiciel vérifie automatiquement ses mises à jour. La collecte des prix et les statistiques anonymes sont activées par défaut et se désactivent séparément dans les réglages. La réception des prix partagés est facultative.

Statistiques anonymes

Dans Réglages > Avancé > Statistiques anonymes, usageStatistics contrôle la participation, indépendamment de la collecte des prix. Une application graphique ouverte envoie immédiatement puis toutes les 30 secondes POST /clients/heartbeat avec exactement {clientId, version}. Le collecteur en arrière-plan n'envoie jamais de présence : les contributions ne font donc pas apparaître une application fermée comme ouverte.

clientId est un UUID v4 aléatoire conservé dans client-id.txt dans le répertoire de données, partagé entre application et collecteur sous verrou de fichier, sans dérivation du compte, du personnage ou de la machine. Les contributions de prix portent les en-têtes facultatifs X-Dostuff-Client et X-Dostuff-Version lorsque la participation est active. La préférence est relue sur disque à chaque envoi réel, y compris une reprise de la file hors ligne ; désactiver retire ces en-têtes sans changer les prix ni leur batchId. Les modifications partielles des préférences relisent le document sous un verrou commun à l'application et au collecteur : la détection d'un serveur ne peut pas réactiver les statistiques après une désactivation.

Ces statistiques ne contiennent ni identité de personnage ou de compte, ni adresse IP, ni information système ou matérielle. L'API ne conserve que l'empreinte SHA-256 de l'UUID, jamais l'UUID brut, pendant 30 jours. Il s'agit d'installations techniques, pas d'un décompte de personnes. Les anciennes versions ne signalant pas leur présence ne peuvent pas être comptées rétrospectivement. Une API ancienne ou indisponible n'empêche ni l'application ni le collecteur de fonctionner.

Les données

Le catalogue vient de DofusDB. La synchronisation lit les statistiques, les types, les gabarits d'effets, les items, les panoplies, les races, les sorts et leurs grades, et écrit le tout dans ~/.local/share/dostuff/encyclopedia.db. Elle ne s'exécute qu'à la demande. Ce qui est connu de l'amont, la version enregistrée et la date de la dernière vérification, vit à côté dans game-data.json, hors du cache, pour ne pas disparaître avec lui.

Les illustrations et les figures sont versionnées dans src/main/resources/assets/ et packagées avec l'application : 12 220 icônes d'items, 3 100 icônes de sorts, 655 éléments d'interface, 53 icônes de caractéristiques, 38 corps et 19 emblèmes de classes, et le nécessaire du personnage animé - squelettes, habillages, atlas et tables, montures et familiers compris - produit à la maintenance par scripts/dofus/export-figure.sh depuis une installation locale du jeu.

Les stuffs enregistrés ne vivent pas dans le cache. Ils sont écrits dans builds.json, dans le répertoire de configuration, parce que la base est un cache que l'application vide et refait dès que son schéma change - ce qui emporterait le travail de l'utilisateur avec.

scripts/dofus/extract-assets.sh les régénère depuis une installation locale du jeu. C'est un outil de maintenance, pas une étape d'installation : on le lance quand le jeu sort de nouvelles illustrations, on relit le diff, on commite, et la build suivante embarque le résultat.

./scripts/dofus/extract-assets.sh                  # tout, en 1x (~8 s)
./scripts/dofus/extract-assets.sh --scale 2x       # la résolution supérieure
./scripts/dofus/extract-assets.sh --only items
./scripts/dofus/extract-assets.sh --verify

Le catalogue interface n'est pas le même ensemble aux deux échelles ; lancer les deux donne l'union, la plus grande résolution d'abord.

Le libellé des effets n'est pas écrit en dur. Le jeu ships ses propres gabarits - #1{{~1~2 à }}#2 dommages Neutre - et l'application les rend telle quelle. Les 24 386 lignes d'effets du catalogue sortent donc avec les mots d'Ankama, et les effets qui n'existent pas encore fonctionneront aussi.

Architecture

Clean Architecture dans un module unique, les frontières tenues par ArchUnit plutôt que par des murs de modules.

Package	Peut importer
domain	rien du projet
data	domain, window
presentation	domain, designsystem
designsystem	les ressources Compose générées
window	rien du projet
app	tout ; rien n'importe app

• domain - Outcome<T> / DomainError : les échecs sont des valeurs, jamais des exceptions traversant une frontière. Un cas d'usage est une classe finale avec un seul operator fun invoke.
• data - SQLDelight sur SQLite pour le cache, java.net.http pour l'aspiration, un parseur pour le langage de critères d'Ankama, et le modèle CP-SAT de l'optimiseur sur Google OR-Tools (natif par plateforme).
• presentation - MVI maison (UiState / UiAction / UiEffect) sur AndroidX Lifecycle. Quatre pages : accueil, encyclopédie, stuff, stuffs enregistrés.
• designsystem - jetons, atomes, molécules, organismes, gabarits. Ne connaît aucun type du domaine.
• window - une couche de chrome de fenêtre qui dessine sa propre barre de titre tout en gardant le déplacement, l'ancrage et le redimensionnement du système. Quatre stratégies choisies par une fonction pure.

Le calculateur est une fonction pure - un BuildDefinition entre, une feuille sort - sans dépôt, sans cache et sans horloge. C'est ce qui permet de prévisualiser au survol l'effet d'un item sans jamais modifier le stuff, puis le défaire : comparer, c'est appeler la fonction deux fois.

Le filtrage se fait en mémoire plutôt qu'en SQL : le catalogue tient dans 4 000 objets, une requête porte un nombre quelconque de seuils, et du SQL assemblé à chaque frappe coûterait plus qu'un balayage.

Détail complet dans docs/architecture.md.

Règles du dépôt

Ce ne sont pas des conventions : ce sont des tests, et une violation casse ./gradlew check.

• Zéro commentaire de code. // et /* */ n'existent nulle part dans src/main. Seul le KDoc est permis.
• Couverture KDoc complète : @param pour chaque paramètre, @property pour chaque propriété publique de constructeur, @return pour tout retour non Unit.
• Frontières de couches, la table ci-dessus en ArchUnit, plus : le domaine ne nomme ni Compose ni AWT ni la sérialisation ; les DTO ne quittent pas data ; un *ViewModel ne nomme aucun type d'interface ; seul un *Screen peut appeler koinViewModel().
• Jetons de design : les littéraux Color(0x…) et .sp uniquement sous designsystem/theme/, les .dp uniquement sous designsystem/ et window/.
• allWarningsAsErrors : un import inutilisé casse le build.

Commandes

./gradlew run                          # l'application
./gradlew check                        # spotless + tests unitaires + suite d'architecture
./gradlew jmh                          # micro-benchmarks JMH, voir docs/benchmarks.md
./gradlew spotlessApply                # ktlint, 140 colonnes, 4 espaces
./gradlew packageDeb                   # paquet Linux
./gradlew packageReleaseDeb            # version réduite par ProGuard
./gradlew createReleaseDistributable   # version portable, sans installateur
./scripts/dofus/extract-assets.sh
./scripts/lucide/sync-icons.sh --verify
./scripts/run-wayland.sh

Attributions

Les données du catalogue proviennent de DofusDB. Utilisation soumise à la LPNC-IA 1.0 : usage strictement non commercial, attribution, et partage à l'identique. Le texte complet est publié sur https://api.dofusdb.fr/.

Données issues de DofusDB. Utilisation soumise à la LPNC-IA 1.0.

Les illustrations et les données de jeu sont la propriété d'Ankama Studio. Elles sont versionnées dans ce dépôt et embarquées dans les paquets uniquement pour afficher les équipements et le personnage ; elles ne sont pas couvertes par la licence Apache 2.0 du code et ne sont pas réutilisables en dehors de cet usage.

Ce dépôt est public et les paquets sont téléchargeables sur https://dostuff.vyxs.fr. Cette mise à disposition se fait sans licence explicite d'Ankama pour ces ressources : elles seront retirées du dépôt et des paquets à la première demande de leurs ayants droit, ou au moindre problème signalé, sans discussion.

Ce dépôt est un projet personnel, sans affiliation avec Ankama ni avec DofusDB.

Les icônes d'interface sont vendorisées depuis Lucide sous licence ISC - voir THIRD_PARTY_NOTICES.md. Le code est publié sous licence Apache 2.0 ; voir LICENSE.