Ajouter un panneau de trophées mural, plaçable dans une maison, qui reflète automatiquement les vraies statistiques du serveur au lieu de contenir un score saisi à la main.
Chaque panneau est lié au joueur qui le pose.
Une page affiche la métrique, le meilleur joueur du serveur et sa valeur, puis le rang et la valeur du propriétaire du panneau. Un détail peut montrer un podium borné aux trois premiers.
Clic droit avec un item : sélectionner ou ajouter les pages liées à cet item (par exemple blocs minés, objets fabriqués, utilisés, cassés ou ramassés quand la statistique existe). L'item sert d'icône mais n'est pas consommé.
Shift + clic droit : passer à la page suivante. Le changement de page est possible pour les visiteurs, mais seul le propriétaire ou un opérateur peut modifier les pages configurées.
Les valeurs et le classement montent automatiquement lorsque les vraies statistiques serveur changent, y compris quand le champion est hors ligne.
La première version est purement informative et cosmétique : aucune récompense automatique afin de ne pas encourager le farm ou les exploits.
Exemples de familles de pages : exploration et progression Sanctuary, découvertes/cuisine/Canaplia de It's Alive, matériaux et photographie d'Another World, machines de Red-Stoner, distances et transports d'I Like To Move It, combat d'Ouch, Lucky Blocks/lootboxes d'Only Fun, plus les statistiques vanilla utiles. Ambiance et Events peuvent enregistrer leurs propres métriques lorsqu'elles ont un événement pertinent. Les actions de test MasterKey, le créatif et le spectateur ne doivent pas gonfler un classement public.
Propriété et intégration
Module propriétaire des classements : Sanctuary, qui possède déjà la progression globale, les profils UUID et les données serveur.
Module propriétaire du bloc : Red-Stoner, responsable des blocs de calcul et d'affichage. ID proposé : redstoner:trophy_panel.
Autres modules appelés : aucun appel direct depuis le panneau. Chaque mod de gameplay enregistre ses métriques auprès d'une API publique Sanctuary avec un Identifier stable, son libellé, son unité/format et sa règle de classement.
API ou donnée partagée : proposer une API de classement serveur distincte de SanctuaryStat (qui représente actuellement les rangs achetés vitalité/faim/minage/etc.). Elle accepte seulement des mutations serveur fiables et fournit des snapshots de podium bornés.
Aucune dépendance vers Red-Stoner depuis les autres mods et aucun cycle Gradle. Les modules déjà dépendants de Sanctuary publient leurs compteurs par l'API Sanctuary.
Sources et persistance
Réutiliser les statistiques vanilla persistantes quand elles décrivent déjà correctement l'action.
Pour les actions propres aux mods, incrémenter des compteurs via des événements serveur au moment de l'action ; ne pas recalculer tous les joueurs ou tous les blocs à chaque tick.
Persister dans Sanctuary un index versionné par UUID et Identifier de métrique, avec data_version, valeur bornée en long, dernier nom connu et date/ordre d'atteinte pour départager de façon déterministe. Les égalités de valeur conservent le même rang.
Prévoir une migration monotone qui importe une fois les statistiques vanilla déjà existantes pour que les anciens joueurs ne repartent pas de zéro.
Le block entity Red-Stoner ne stocke que propriétaire, liste bornée de pages, item/icône, page courante et data_version ; il ne duplique jamais les scores.
Ne jamais exposer de donnée sensible comme le solde d'un coffre-fort, la position précise, l'inventaire ou une information d'administration.
Réseau et autorité
Le client envoie seulement l'interaction demandée. Le serveur vérifie joueur, distance, bloc chargé, propriétaire/opérateur, item et index de page.
Le serveur renvoie uniquement la page visible et un podium borné (trois entrées, Identifiers et noms limités), pas la base complète des joueurs.
Rafraîchir sur événement/changement avec un débit limité, au maximum une fois par seconde par panneau observé ; aucun scan global par tick.
Incrémenter les protocoles Sanctuary et Red-Stoner si de nouveaux payloads sont nécessaires et refuser proprement les clients incompatibles ou les requêtes invalides.
Critères d'acceptation
En multijoueur, trois joueurs produisent des statistiques vanilla et de plusieurs mods ; chaque page désigne le bon premier et affiche le rang réel du propriétaire.
Le classement reste correct après déconnexion du champion, redémarrage du serveur et rechargement du chunk.
Un clic droit avec un item sélectionne des pages compatibles sans consommer ni copier l'item ; un item sans métrique donne un message clair.
Shift + clic droit boucle sur un nombre de pages borné sans ouvrir d'écran ni envoyer de spam réseau.
Un visiteur peut consulter/changer la page visible mais ne peut pas reconfigurer le panneau ; le propriétaire et un opérateur le peuvent.
Créatif, spectateur, commandes MasterKey, entités temporaires et actions simulées ne faussent pas les métriques publiques.
Les anciens mondes et statistiques vanilla sont migrés sans perte et les données d'une version plus récente ne sont pas réécrites à l'aveugle.
Textes, noms de pages, unités et messages existent en FR/EN/RU.
Tests unitaires sur tri, égalités, bornes, migration et permissions ; tests d'intégration réseau/bloc ; :sanctuary:check, :redstoner:check, les checks des modules contributeurs et ./gradlew check passent.
Découpage proposé
Sanctuary : contrat public des métriques, stockage versionné, import vanilla, classement et tests.
Red-Stoner : bloc, block entity, rendu en monde, interactions et payloads bornés sur une métrique factice.
Intégrations par petites PR indépendantes : chaque mod enregistre quelques métriques fiables sans dépendance vers Red-Stoner.
Ressources, recette de survie, traductions FR/EN/RU, versions des modules touchés et validation multijoueur.
Hors périmètre de la première version : saisons hebdomadaires/mensuelles, récompenses de classement et mur multi-blocs. L'API pourra rester réutilisable plus tard par le Personal Computer ou l'écran Statistics.
## Résultat joueur attendu
Ajouter un panneau de trophées mural, plaçable dans une maison, qui reflète automatiquement les vraies statistiques du serveur au lieu de contenir un score saisi à la main.
- Chaque panneau est lié au joueur qui le pose.
- Une page affiche la métrique, le meilleur joueur du serveur et sa valeur, puis le rang et la valeur du propriétaire du panneau. Un détail peut montrer un podium borné aux trois premiers.
- Clic droit avec un item : sélectionner ou ajouter les pages liées à cet item (par exemple blocs minés, objets fabriqués, utilisés, cassés ou ramassés quand la statistique existe). L'item sert d'icône mais n'est pas consommé.
- Shift + clic droit : passer à la page suivante. Le changement de page est possible pour les visiteurs, mais seul le propriétaire ou un opérateur peut modifier les pages configurées.
- Les valeurs et le classement montent automatiquement lorsque les vraies statistiques serveur changent, y compris quand le champion est hors ligne.
- La première version est purement informative et cosmétique : aucune récompense automatique afin de ne pas encourager le farm ou les exploits.
Exemples de familles de pages : exploration et progression Sanctuary, découvertes/cuisine/Canaplia de It's Alive, matériaux et photographie d'Another World, machines de Red-Stoner, distances et transports d'I Like To Move It, combat d'Ouch, Lucky Blocks/lootboxes d'Only Fun, plus les statistiques vanilla utiles. Ambiance et Events peuvent enregistrer leurs propres métriques lorsqu'elles ont un événement pertinent. Les actions de test MasterKey, le créatif et le spectateur ne doivent pas gonfler un classement public.
## Propriété et intégration
- Module propriétaire des classements : Sanctuary, qui possède déjà la progression globale, les profils UUID et les données serveur.
- Module propriétaire du bloc : Red-Stoner, responsable des blocs de calcul et d'affichage. ID proposé : redstoner:trophy_panel.
- Autres modules appelés : aucun appel direct depuis le panneau. Chaque mod de gameplay enregistre ses métriques auprès d'une API publique Sanctuary avec un Identifier stable, son libellé, son unité/format et sa règle de classement.
- API ou donnée partagée : proposer une API de classement serveur distincte de SanctuaryStat (qui représente actuellement les rangs achetés vitalité/faim/minage/etc.). Elle accepte seulement des mutations serveur fiables et fournit des snapshots de podium bornés.
- Aucune dépendance vers Red-Stoner depuis les autres mods et aucun cycle Gradle. Les modules déjà dépendants de Sanctuary publient leurs compteurs par l'API Sanctuary.
### Sources et persistance
- Réutiliser les statistiques vanilla persistantes quand elles décrivent déjà correctement l'action.
- Pour les actions propres aux mods, incrémenter des compteurs via des événements serveur au moment de l'action ; ne pas recalculer tous les joueurs ou tous les blocs à chaque tick.
- Persister dans Sanctuary un index versionné par UUID et Identifier de métrique, avec data_version, valeur bornée en long, dernier nom connu et date/ordre d'atteinte pour départager de façon déterministe. Les égalités de valeur conservent le même rang.
- Prévoir une migration monotone qui importe une fois les statistiques vanilla déjà existantes pour que les anciens joueurs ne repartent pas de zéro.
- Le block entity Red-Stoner ne stocke que propriétaire, liste bornée de pages, item/icône, page courante et data_version ; il ne duplique jamais les scores.
- Ne jamais exposer de donnée sensible comme le solde d'un coffre-fort, la position précise, l'inventaire ou une information d'administration.
### Réseau et autorité
- Le client envoie seulement l'interaction demandée. Le serveur vérifie joueur, distance, bloc chargé, propriétaire/opérateur, item et index de page.
- Le serveur renvoie uniquement la page visible et un podium borné (trois entrées, Identifiers et noms limités), pas la base complète des joueurs.
- Rafraîchir sur événement/changement avec un débit limité, au maximum une fois par seconde par panneau observé ; aucun scan global par tick.
- Incrémenter les protocoles Sanctuary et Red-Stoner si de nouveaux payloads sont nécessaires et refuser proprement les clients incompatibles ou les requêtes invalides.
## Critères d'acceptation
- [ ] En multijoueur, trois joueurs produisent des statistiques vanilla et de plusieurs mods ; chaque page désigne le bon premier et affiche le rang réel du propriétaire.
- [ ] Le classement reste correct après déconnexion du champion, redémarrage du serveur et rechargement du chunk.
- [ ] Un clic droit avec un item sélectionne des pages compatibles sans consommer ni copier l'item ; un item sans métrique donne un message clair.
- [ ] Shift + clic droit boucle sur un nombre de pages borné sans ouvrir d'écran ni envoyer de spam réseau.
- [ ] Un visiteur peut consulter/changer la page visible mais ne peut pas reconfigurer le panneau ; le propriétaire et un opérateur le peuvent.
- [ ] Créatif, spectateur, commandes MasterKey, entités temporaires et actions simulées ne faussent pas les métriques publiques.
- [ ] Les anciens mondes et statistiques vanilla sont migrés sans perte et les données d'une version plus récente ne sont pas réécrites à l'aveugle.
- [ ] Textes, noms de pages, unités et messages existent en FR/EN/RU.
- [ ] Tests unitaires sur tri, égalités, bornes, migration et permissions ; tests d'intégration réseau/bloc ; :sanctuary:check, :redstoner:check, les checks des modules contributeurs et ./gradlew check passent.
## Découpage proposé
1. Sanctuary : contrat public des métriques, stockage versionné, import vanilla, classement et tests.
2. Red-Stoner : bloc, block entity, rendu en monde, interactions et payloads bornés sur une métrique factice.
3. Intégrations par petites PR indépendantes : chaque mod enregistre quelques métriques fiables sans dépendance vers Red-Stoner.
4. Ressources, recette de survie, traductions FR/EN/RU, versions des modules touchés et validation multijoueur.
Hors périmètre de la première version : saisons hebdomadaires/mensuelles, récompenses de classement et mur multi-blocs. L'API pourra rester réutilisable plus tard par le Personal Computer ou l'écran Statistics.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Résultat joueur attendu
Ajouter un panneau de trophées mural, plaçable dans une maison, qui reflète automatiquement les vraies statistiques du serveur au lieu de contenir un score saisi à la main.
Exemples de familles de pages : exploration et progression Sanctuary, découvertes/cuisine/Canaplia de It's Alive, matériaux et photographie d'Another World, machines de Red-Stoner, distances et transports d'I Like To Move It, combat d'Ouch, Lucky Blocks/lootboxes d'Only Fun, plus les statistiques vanilla utiles. Ambiance et Events peuvent enregistrer leurs propres métriques lorsqu'elles ont un événement pertinent. Les actions de test MasterKey, le créatif et le spectateur ne doivent pas gonfler un classement public.
Propriété et intégration
Sources et persistance
Réseau et autorité
Critères d'acceptation
Découpage proposé
Hors périmètre de la première version : saisons hebdomadaires/mensuelles, récompenses de classement et mur multi-blocs. L'API pourra rester réutilisable plus tard par le Personal Computer ou l'écran Statistics.