Files

T

Antone Barbaud a94bc56a5b feat: configurable broadcasts + /core reload

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>

2026-06-10 11:16:34 +02:00

4.5 KiB

Raw Blame History

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 / SubCommand imbriqué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 @EventHandler côté plugin de jeu.
Persistance SQLite — wrapper Database + TableBuilder fluide, repositories SQLite write-through, table custom en 2 lignes pour les plugins downstream.
Messages externalisés — MessagesService charge un seul fichier YAML <plugin>-messages.yml dans 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 — BroadcastService route 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 reload recharge les deux fichiers à chaud.
Bootstrap unique — new CRCore(this).enable() dans le onEnable() 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és protected, hooks onBefore…/onAfter… et factories new… 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.

4.5 KiB Raw Blame History