Antone Barbaud
a94bc56a5b
New fr.luc.crcore.broadcast module: - BroadcastAudience enum (NONE, LEADER, TEAM, ADMIN, ALL). - BroadcastContext (fluent: team + involvedPlayerId + placeholders). - BroadcastService interface + YamlBroadcastService impl. - CRCoreBroadcastListener (Bukkit listener) wires the 12 native events (9 team + 3 player) to broadcasts.broadcast(eventKey, ctx). Same single-per-plugin file pattern as messages: <plugin-dataFolder>/<plugin-name-lowercase>-broadcasts.yml. Defaults bundled at resources/crcore-broadcasts.yml, copied on first boot (game plugin's own resource of the same name takes priority as the template). In-memory fallback so new CR-Core keys work without admin edit. Routes (who) vs templates (what) are separated: broadcasts.yml lists audiences per eventKey, messages.yml contains the templates under keys <eventKey>.broadcast. Admin can change either independently. 12 new *.broadcast keys added to crcore-messages.yml with sensible French defaults and color codes. Listener injects standard placeholders (name, team_name, tag, color, visibility, player, new_leader, old/new_value, etc.). ADMIN audience resolved via crcore.broadcast.admin permission. Multi- audiences via YAML list (e.g., [TEAM, ADMIN]); union of resolved players, no duplicate. New /core reload subcommand (permission crcore.reload) hot-reloads both messages and broadcasts from disk without restart. CRCore: protected buildBroadcastService() override point, getter broadcasts(), wire of CRCoreBroadcastListener at enable(). CoreCommand constructor extended to take BroadcastService, registers the reload subcommand. Docs/features.md: new section 9 "Service de broadcasts". docs/setup.md: updated to mention both YAML files. decisions.md logs the routes-vs- templates split, the audience model, and the reload semantics. New diagram broadcasts-class-diagram.puml. README updated. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Documentation CR-Core
Ce dossier est la source de vérité du projet. Toutes les décisions, idées, mécaniques, règles et spécifications du noyau sont consignées ici.
Objectif du projet
CR-Core est une librairie Maven réutilisable pour construire des plugins Minecraft Paper 1.16.5. Elle fournit, prêt à l'emploi en une ligne d'initialisation côté plugin de jeu :
- Abstractions communes —
Identifiable,Named,ScoreHolder,AbstractEntity,Repository<T>. - Domaine Team — équipes (nom, tag, couleur, chef, membres, visibilité PUBLIC/PRIVATE, scores nommés, classements, point de spawn), service overridable, exceptions dédiées.
- Domaine Player — profils joueurs (scores nommés, classements individuels), service auto-créant les profils à la demande.
- Framework de commandes —
BaseCommand/SubCommandimbriqués, arguments typés, tab-complétion, permissions, player-only. - Commandes par défaut —
/core team [create|delete|add|remove|join|leave|info|list|transfer|visibility|score|top|setspawn]fonctionnelles out-of-the-box, chacune substituable par sous-classe. - Évènements Bukkit — 9 events team + 3 events player, à écouter avec
@EventHandlercôté plugin de jeu. - Persistance SQLite — wrapper
Database+TableBuilderfluide, repositories SQLite write-through, table custom en 2 lignes pour les plugins downstream. - Messages externalisés —
MessagesServicecharge un seul fichier YAML<plugin>-messages.ymldans le dataFolder du plugin de jeu, avec defaults CR-Core en fallback. L'admin édite un seul fichier, placeholders nommés, codes couleur&natifs. - Broadcasts configurables —
BroadcastServiceroute chaque event CR-Core vers une liste d'audiences (NONE,LEADER,TEAM,ADMIN,ALL) définie dans<plugin>-broadcasts.yml. Séparation routes / templates. Un listener interne wire les 12 events natifs ; les game plugins peuvent broadcast leurs propres events./core reloadrecharge les deux fichiers à chaud. - Bootstrap unique —
new CRCore(this).enable()dans leonEnable()du plugin de jeu, et tout est branché.
Structure de la documentation
README.md— Ce fichier. Vue d'ensemble et index.setup.md— Build, intégration dans un plugin de jeu, exemple d'usage.features.md— Domaines fonctionnels détaillés.decisions.md— Journal des décisions importantes (ADR léger).diagrams/— Diagrammes PlantUML (.puml).
Diagrammes
| Fichier | Type | Sujet |
|---|---|---|
| team-class-diagram.puml | Classe | Domaine Team + abstractions communes |
| team-create-sequence.puml | Séquence | Création d'une équipe via la commande |
| team-join-sequence.puml | Séquence | Auto-join sur une équipe publique |
| team-create-activity.puml | Activité | Flux de validation à la création |
| player-class-diagram.puml | Classe | Domaine Player + scores joueur |
| command-class-diagram.puml | Classe | Framework de commandes (nested) |
| builtin-commands-diagram.puml | Classe | Arbre des commandes /core team ... |
| events-diagram.puml | Classe | Évènements Bukkit team + player |
| database-diagram.puml | Classe | Wrapper SQLite + table builder |
| messages-class-diagram.puml | Classe | Service de messages YAML |
| broadcasts-class-diagram.puml | Classe | Service de broadcasts YAML + listener |
| bootstrap-sequence.puml | Séquence | CRCore.enable() côté plugin de jeu |
Conventions
- Code : anglais standard, séparation stricte interfaces / enums / classes abstraites / classes concrètes / exceptions.
- Doc & messages joueur : français.
- JavaDoc en français sur les classes publiques et méthodes non triviales.
- Package racine :
fr.luc.crcore. - Classes du noyau non-
final, méthodes-clésprotected, hooksonBefore…/onAfter…et factoriesnew…pour l'override.
Contribuer à la doc
Chaque nouvelle idée, règle, commande ou contrainte discutée doit être ajoutée au fichier approprié, avant ou pendant l'implémentation. La doc précède le code.