T

Antone Barbaud 75d2fa866d feat: typed team settings (cascade per-team → global → default) + in-game GUI

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>

2026-06-10 11:46:51 +02:00

.idea

feat: SQLite persistence, default /core commands, Bukkit events, bootstrap

2026-06-09 10:54:00 +02:00

docs

feat: typed team settings (cascade per-team → global → default) + in-game GUI

2026-06-10 11:46:51 +02:00

src/main

feat: typed team settings (cascade per-team → global → default) + in-game GUI

2026-06-10 11:46:51 +02:00

.gitignore

feat: initial CR-Core library (team + player + command framework)

2026-06-08 17:17:56 +02:00

GEMINI.md

feat: SQLite persistence, default /core commands, Bukkit events, bootstrap

2026-06-09 10:54:00 +02:00

pom.xml

feat: chef commands moved to admin + PlaceholderAPI integration

2026-06-09 15:05:02 +02:00

docs/README.md

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	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
team-config-class-diagram.puml	Classe	Paramètres d'équipe (cascade + GUI)
gui-class-diagram.puml	Classe	Framework GUI réutilisable
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.