186 lines
11 KiB
Markdown
186 lines
11 KiB
Markdown
# Métabli — atelier de construction et catalogue extensible
|
||
|
||
Statut : **conception de référence**, le 16 septembre 2026.
|
||
Le catalogue, les commandes K et l’exemple généré évoluent dans
|
||
[beta.099](catalogue-progression-beta099.md).
|
||
Le premier lot est livré dans [beta.096](metabli-beta096.md), branche
|
||
`codex/metabli-beta096` : multibloc, catalogue et commandes de construction.
|
||
Les chantiers partagés persistants, datapacks de catalogue et services décrits
|
||
ci-dessous restent des propositions pour les lots suivants. Le contrat beta.096
|
||
précise le fonctionnement effectivement implémenté.
|
||
|
||
## Direction demandée
|
||
|
||
Un multibloc posé dans le monde ouvre le menu de construction. Aucun bouton
|
||
supplémentaire dans le menu pause. Le système réunit statues, machines et
|
||
bâtiments, et doit pouvoir accueillir de nouveaux contenus et usages.
|
||
« Métabli » reprend ici le nom du nouveau message ; le catalogue historique
|
||
employait « Métablit ». Aucun identifiant publié n'est renommé.
|
||
|
||
## Ce que le jeu possède déjà
|
||
|
||
- `PlansScreen` propose Statue, Bibliothèque et Construction via K.
|
||
- `StatueVoxelizer` et la capture cliente produisent des statues à partir des
|
||
modèles et textures du jeu ; `BuildPlan` porte les blocs et leurs états.
|
||
- `PlanClient` sait ancrer un aperçu, le tourner, isoler une couche et compter
|
||
les blocs corrects, restants et en conflit. Cet état est actuellement local.
|
||
- `SchematicIO` lit les formats pris en charge dans la bibliothèque ; l'import
|
||
ne reprend pas les inventaires, scripts ou entités des fichiers tiers.
|
||
- `PlanService` autorise le collage uniquement en créatif. En survie, le joueur
|
||
pose aujourd'hui ses blocs lui-même : aucun moteur de chantier automatique.
|
||
- La clé dorée et les machines existantes donnent un précédent pour l'assemblage
|
||
volontaire, la dissociation et l'autorité serveur.
|
||
|
||
Références : [plans existants](statues-plans-beta072.md),
|
||
[multiblocs existants](multiblocs-beta084.md),
|
||
[catalogue historique](multiblocs-conception.md).
|
||
|
||
## Le Métabli dans le monde
|
||
|
||
Proposition de forme : **neuf établis à plat, en 3 × 3 sur un bloc de hauteur**,
|
||
assemblés volontairement avec la clé dorée. Forme et apparence à confirmer
|
||
avant le code ; ne pas imposer les 27 composants du Fourneau à cette machine.
|
||
Un clic droit sur un composant assemblé ouvre le même atelier.
|
||
|
||
Le Métabli sert à choisir, préparer et gérer un projet. La construction est
|
||
ancrée à un autre emplacement choisi dans le monde ; elle n'a pas à occuper
|
||
la place de l'atelier. L'aperçu indique clairement sa base et son orientation.
|
||
Proposition initiale : un chantier actif par Métabli, plusieurs participants.
|
||
|
||
K reste disponible pour l'aperçu et les réglages du plan en cours. Le premier
|
||
lot ne supprime pas les outils locaux déjà livrés ; le nouveau catalogue et
|
||
la gestion du chantier partagé sont accessibles depuis le Métabli.
|
||
|
||
## Un menu commun
|
||
|
||
Interface native et sobre : catégories en haut, liste et recherche à gauche,
|
||
aperçu et fiche du projet à droite, actions en bas. Les catégories n'ouvrent
|
||
pas quatre nouveaux menus indépendants.
|
||
|
||
| Catégorie | Contenu | Réglages utiles |
|
||
| --- | --- | --- |
|
||
| Statues | Générateur actuel de mobs ; autres modèles ultérieurement | Modèle, taille, palette |
|
||
| Machines | Fourneau, Fût, super pistons ; plans de circuits redstone validés | Orientation, variante, entrées et sorties |
|
||
| Bâtiments | Maisons, ateliers, ponts et autres plans ajoutés au catalogue | Dimensions, variantes de matériaux compatibles |
|
||
| Mes plans | Bibliothèque locale et imports actuels | Nom, dimensions, matériaux, rotation |
|
||
|
||
Une fiche affiche la fonction réelle, l'encombrement, les matériaux requis
|
||
et manquants, ainsi que la condition de déblocage éventuelle. Les exemples de
|
||
bâtiments et de circuits ci-dessus sont des contenus à créer, pas un catalogue
|
||
déjà présent. Une fonction absente du jeu n'est pas présentée comme disponible.
|
||
|
||
Parcours proposé : choisir → configurer → positionner l'aperçu → confirmer
|
||
l'emplacement → construire → utiliser. Une fiche de chantier conserve
|
||
l'avancement et les besoins en matériaux. Le mode retenu par le créateur est la **construction manuelle guidée** :
|
||
les joueurs apportent leurs matériaux et posent eux-mêmes les blocs.
|
||
|
||
## Mode retenu : construction manuelle guidée
|
||
|
||
Décision confirmée par le créateur le 16 septembre 2026. Le Métabli ne place
|
||
pas les blocs et ne prélève pas les objets. La pose, les outils, les matériaux
|
||
et les règles de voisinage restent ceux du jeu. Aucun moteur automatique,
|
||
réserve de chantier, délai de fabrication ou consommation différée à créer.
|
||
|
||
Réutiliser l'aperçu existant : les blocs terminés s'effacent de la projection,
|
||
les conflits sont signalés et les couches permettent de suivre un grand plan.
|
||
Le chantier commun pourra partager l'ancrage et la progression ; chaque joueur
|
||
contribue avec son propre inventaire. Le contrôle de droits sur la construction
|
||
elle-même reste celui du monde, indépendamment des droits d'édition du plan.
|
||
|
||
La fiche distingue **blocs à placer** et **objets nécessaires**. Le compteur
|
||
actuel travaille sur les états de blocs ; annoncer une liste exacte d'objets
|
||
exige d'adapter les portes et lits (un objet, deux cases), les dalles doubles
|
||
(deux objets) et les autres cas particuliers. Aucun de ces calculs ne peut
|
||
modifier ou doubler la consommation native du joueur.
|
||
|
||
## Une construction a un plan et, parfois, une fonction
|
||
|
||
Le **plan** décrit la forme : blocs, états, variantes et points de raccordement.
|
||
La **fonction** décrit un comportement éventuellement ajouté par Sanctuary.
|
||
|
||
- Une statue ou une maison ordinaire a seulement besoin de son plan.
|
||
- Un circuit redstone fonctionne grâce aux blocs réellement construits.
|
||
- Un Fourneau doit en plus être validé et assemblé par le système existant.
|
||
- Une boutique aura besoin d'un composant commercial : propriétaire, stock,
|
||
offres et échanges. Construire son bâtiment ne crée pas ce service à lui seul.
|
||
|
||
Pour les machines reconnues, le plan complet et les permissions sont vérifiés
|
||
avant l'assemblage final ; un simple import de blocs ne peut pas s'attribuer une
|
||
fonction spéciale. Les ports indiqués dans le plan tournent avec la structure
|
||
(entrée d'objets, sortie, commande redstone, face d'interaction).
|
||
|
||
La demande de boutique donne un point d'extension, **pas une livraison de
|
||
l'économie maintenant**. On pourra préparer un local de boutique et lui
|
||
rattacher le service lorsque le commerce sera défini et implémenté. Son futur
|
||
signal redstone pourra par exemple indiquer un stock disponible ou une vente,
|
||
sans confondre le signal avec l'opération d'échange elle-même.
|
||
|
||
## Étendre le catalogue sans refaire l'interface
|
||
|
||
Proposition : des définitions de catalogue en datapack serveur, avec des
|
||
identifiants stables et une version de définition. Une entrée comporte :
|
||
|
||
- nom et description FR/EN, catégorie et tags ;
|
||
- source du plan ou générateur connu, paramètres et variantes autorisées ;
|
||
- condition de déblocage vérifiable côté serveur ;
|
||
- matériaux et opérations de placement, calculés depuis la variante retenue ;
|
||
- ports de raccordement et type de fonction facultatif.
|
||
|
||
Ajouter un bâtiment ou un circuit utilisant les mécanismes existants revient
|
||
à ajouter un plan et sa fiche. Une nouvelle mécanique, comme le commerce ou
|
||
une machine inédite, demande un module de code serveur enregistré, puis une
|
||
fiche qui l'utilise. Un datapack ne devient pas un interpréteur de commandes
|
||
arbitraires et un fichier importé ne fournit pas son propre code exécutable.
|
||
|
||
Les générateurs de statues et les fichiers locaux deviennent deux fournisseurs
|
||
de plans parmi d'autres. Les catégories servent à naviguer ; elles ne dictent
|
||
pas le moteur de placement. Découvertes, advancements ou aptitudes pourront
|
||
débloquer des entrées, sans supposer que ces règles existent déjà pour les plans.
|
||
|
||
## Persistance et reprise à définir avant le code
|
||
|
||
Le registre actuel des multiblocs décrit un cube de 27 cases avec un booléen
|
||
Fourneau/Fût. Il n'est pas extensible à un Métabli par ajout d'une troisième
|
||
valeur. Prévoir un registre dédié pour cette nouvelle machine et ses chantiers,
|
||
sans modifier le schéma existant ; un contrôle commun empêchera de partager
|
||
un composant avec les anciennes machines.
|
||
|
||
Le futur contrat versionné devra fixer l'identité du Métabli et du projet,
|
||
la dimension, l'ancrage, l'orientation, les droits d'édition et la reprise
|
||
du suivi. Les matériaux restent dans les inventaires Minecraft ; aucun stock
|
||
dupliqué n'appartient au plan. Conserver une copie bornée du plan
|
||
validé et de sa révision évite qu'une mise à jour du catalogue transforme un
|
||
chantier en cours ou un bâtiment déjà posé. Les limites actuelles de `BuildPlan`
|
||
restent le point de départ, pas une promesse de gros plans sans limite.
|
||
|
||
Proposition de règles : aucune transformation automatique des établis existants ;
|
||
la projection n'écrase jamais le terrain ; suivi suspendu hors chunks chargés,
|
||
sans forcer leur chargement. Une casse du Métabli ou une annulation du projet
|
||
ne supprime aucun bloc déjà posé et ne restitue pas de matériaux déjà utilisés.
|
||
Les projets complets ne déclenchent pas une deuxième production.
|
||
L'activation d'une machine reconnue reste une action explicite, après contrôle
|
||
serveur, selon les règles de la clé. Le suivi partagé doit persister le plan,
|
||
pas une copie ancienne du monde à rejouer après reconnexion.
|
||
|
||
Ces règles et ce registre sont un cadrage, **pas une migration approuvée ni un
|
||
format livré**. La forme du Métabli, les droits de gestion, le rayon d'ancrage
|
||
et les déblocages restent à fixer avant le lot concerné.
|
||
|
||
## Lots proposés
|
||
|
||
1. Métabli ouvrable, interface commune, statues et bibliothèque actuelles,
|
||
sélection d'un plan et projection à l'emplacement voulu. Aucun bouton pause.
|
||
2. Chantier manuel partagé et persistant ; liste correcte des matériaux,
|
||
synchronisation du suivi et vérifications de reprise/annulation.
|
||
3. Catalogue initial de machines et bâtiments validés, assemblage final des
|
||
machines existantes et protocole d'ajout de contenu en datapack.
|
||
4. Modules de fonction supplémentaires lorsque leur gameplay est défini,
|
||
notamment le commerce ; hors premier lot.
|
||
|
||
Chaque lot devra avoir un résultat jouable, un contrat de sauvegarde s'il en
|
||
crée un, les libellés FR/EN et les vérifications client/serveur adaptées.
|
||
La validation du chantier manuel devra notamment couvrir deux joueurs, une
|
||
pose qui consomme réellement l'objet natif, un obstacle ajouté pendant la
|
||
construction, une porte/un lit, un circuit, le déchargement, la reconnexion et
|
||
la casse du Métabli sans disparition des blocs construits.
|