Antone Barbaud
75d2fa866d
New fr.luc.crcore.team.config module: - TeamSetting<T> (typed, with key/type/default/parser/serializer; factories ofBoolean/ofInt/ofString/ofEnum). - TeamSettings registry: 8 standard settings (FRIENDLY_FIRE, PVP_PROTECTION_SECONDS, MAX_SIZE, MIN_SIZE, RESPAWN_AT_TEAM_SPAWN, TEAM_CHAT_ENABLED, SHOW_TAG_ABOVE_HEAD, TEAM_COLOR_IN_NAME), extensible via register() for game plugins. - TeamConfigService interface with cascade get(team, setting) → per-team override (SQLite) → global YAML → hard default. Persists per- team via TeamRepository.save(), global via YamlConfiguration.save(). - YamlTeamConfigService default impl with bundled crcore-team-config.yml. Storage: - Team.getSettings() Map<String, Object> for per-team overrides. - New SQLite table crcore_team_settings (team_id, key, value, type) with load + write-through persist in SqliteTeamRepository. - Global YAML <plugin>-team-config.yml in dataFolder, auto-created at first boot (template from game plugin's resource of the same name takes priority). New reusable GUI framework fr.luc.crcore.gui: - AbstractInventoryGui (implements InventoryHolder, rebuild() abstract, setButton/setDecoration/clearSlot helpers, onClose hook, openTo()). - GuiClickHandler FunctionalInterface. - GuiListener (single Bukkit listener, detects via getHolder(), ALWAYS cancels clicks even on slots without handlers). - GuiItems builder (named/of/filler + lore/amount/build, '&' color codes translated). Concrete settings GUIs (fr.luc.crcore.team.config.gui): - AbstractSettingsGui base renderer: 27 slots, settings in row 2, booleans = LIME_DYE / GRAY_DYE toggle, integers = BOOK with left +1 / right -1 (shift × 10), strings/enums display-only. - GlobalSettingsGui: writes to YAML on each change. - TeamSettingsGui: writes to per-team overrides, "override active" flag in lore when value differs from global, "Reset all overrides" footer button. New /core team settings [team] subcommand: - No arg → GlobalSettingsGui (perm crcore.team.settings.global). - With arg → TeamSettingsGui (perm crcore.team.settings). - Player-only (Bukkit needs HumanEntity to open inventory). - Lives under /core team to stay modular (objective: split into modules later; everything team-related under /core team). CRCore: buildTeamConfigService() override point, teamConfig()/getTeamConfig() getters, GuiListener.registerOn(plugin) at enable(). CoreCommand, TeamGroupSubCommand and CoreReloadSubCommand extended to receive TeamConfigService. /core reload now reloads messages + broadcasts + team-config. Docs: new section 10 "Paramètres d'équipe", new decisions logged, setup.md tree updated, two new diagrams (team-config + gui). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
92 lines
5.2 KiB
Markdown
92 lines
5.2 KiB
Markdown
# 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.
|
|
- **Paramètres d'équipe** — `TeamConfigService` typé avec cascade
|
|
per-team → global → default. 8 settings standards
|
|
(`FRIENDLY_FIRE`, `MAX_SIZE`, etc.), étendable. Globaux dans
|
|
`<plugin>-team-config.yml`, per-team en SQLite. GUI in-game via
|
|
`/core team settings [team]`.
|
|
- **Framework GUI** — `AbstractInventoryGui` + `GuiListener` réutilisable
|
|
pour tout GUI custom. Détection par holder, clic toujours annulé,
|
|
`GuiItems` builder fluide avec codes couleur `&`.
|
|
- **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](diagrams/team-class-diagram.puml) | Classe | Domaine Team + abstractions communes |
|
|
| [team-create-sequence.puml](diagrams/team-create-sequence.puml) | Séquence | Création d'une équipe via la commande |
|
|
| [team-join-sequence.puml](diagrams/team-join-sequence.puml) | Séquence | Auto-join sur une équipe publique |
|
|
| [team-create-activity.puml](diagrams/team-create-activity.puml) | Activité | Flux de validation à la création |
|
|
| [player-class-diagram.puml](diagrams/player-class-diagram.puml) | Classe | Domaine Player + scores joueur |
|
|
| [command-class-diagram.puml](diagrams/command-class-diagram.puml) | Classe | Framework de commandes (nested) |
|
|
| [builtin-commands-diagram.puml](diagrams/builtin-commands-diagram.puml) | Classe | Arbre des commandes `/core team ...` |
|
|
| [events-diagram.puml](diagrams/events-diagram.puml) | Classe | Évènements Bukkit team + player |
|
|
| [database-diagram.puml](diagrams/database-diagram.puml) | Classe | Wrapper SQLite + table builder |
|
|
| [messages-class-diagram.puml](diagrams/messages-class-diagram.puml) | Classe | Service de messages YAML |
|
|
| [broadcasts-class-diagram.puml](diagrams/broadcasts-class-diagram.puml) | Classe | Service de broadcasts YAML + listener |
|
|
| [team-config-class-diagram.puml](diagrams/team-config-class-diagram.puml) | Classe | Paramètres d'équipe (cascade + GUI) |
|
|
| [gui-class-diagram.puml](diagrams/gui-class-diagram.puml) | Classe | Framework GUI réutilisable |
|
|
| [bootstrap-sequence.puml](diagrams/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.
|