128 lines
7.2 KiB
Markdown
128 lines
7.2 KiB
Markdown
# beta.010 — Inventaire, contrat préalable de migration
|
||
|
||
Ticket PROG-02C, branche `codex/progression-inventory`. Portage demandé le
|
||
13 septembre 2026 depuis `../26.2/sanctuary`, consulté en lecture seule.
|
||
|
||
## Capacité et adoption
|
||
|
||
Une rangée contient neuf cases. La barre rapide compte dans les six rangées :
|
||
le départ est de neuf cases et le plafond de 54, hors armure et seconde main.
|
||
Inventaire possède cinq achats, aux cinq premiers coûts de compétences
|
||
(1, 2, 4, 8 et 16 niveaux par défaut). Les cinq autres compétences gardent
|
||
leurs sept achats. Les opérateurs en survie suivent les mêmes capacités.
|
||
|
||
La progression passe du schéma 4 au schéma 5 par ajout de `inventory: 0`.
|
||
Les schémas 1–3 passent d'abord par leurs migrations existantes. Dates,
|
||
coûts, rangs acquis, aptitudes et révision restent inchangés. Le nouveau
|
||
plafond de l'historique est de 42 achats. Aucune migration du terrain.
|
||
|
||
Les 36 cases vanilla gardent leurs indices et leurs objets. Une case déjà
|
||
occupée dans une rangée non acquise reste visible et permet de retirer son
|
||
contenu ; elle refuse tout ajout. La rangée disparaît de la présentation
|
||
après fermeture du menu si elle est vide et toujours verrouillée. Aucune
|
||
capacité n'est offerte et aucun objet n'est effacé pour adopter la progression.
|
||
Cette règle prépare une réduction future ; aucun New Game+ n'est activé ici.
|
||
|
||
Les 18 cases supplémentaires sont enregistrées avec les données du joueur,
|
||
dans un champ Sanctuary distinct et versionné, lors du même enregistrement
|
||
que l'inventaire vanilla. Les composants des objets sont conservés. Le format
|
||
26.2 de stockage global n'est pas importé automatiquement : ce ticket porte
|
||
le fonctionnement et les ressources, pas les anciennes sauvegardes 26.2.
|
||
Sans `keepInventory`, les objets supplémentaires suivent la mort native et
|
||
sont retirés de l'ancien inventaire une seule fois. Avec `keepInventory`,
|
||
ils sont repris par le nouveau joueur. Les achats persistent dans les deux cas.
|
||
|
||
## Interfaces et protocole
|
||
|
||
Le serveur exige la capacité réseau `sanctuary:inventory_layout_v1` avant
|
||
la création du joueur. Un client ancien est refusé avant le spawn ; un client
|
||
beta.010 refuse également un serveur envoyant une progression antérieure au
|
||
schéma 5. Les migrations sur disque restent possibles côté serveur. Client
|
||
et serveur doivent être mis à jour ensemble pour ce nouveau protocole.
|
||
|
||
Les emplacements supplémentaires sont ajoutés après tous les emplacements
|
||
natifs des menus, afin de garder les indices des machines, de la fabrication,
|
||
des armures et de la seconde main. Les règles d'insertion sont contrôlées sur
|
||
le serveur, y compris pour les transferts rapides et les clics envoyés par un
|
||
client. Les objets récupérables des anciennes rangées ne deviennent pas une
|
||
réserve dans laquelle on peut déposer à nouveau.
|
||
|
||
Les six fonds d'inventaire et les variantes des conteneurs proviennent de
|
||
26.2. Les emplacements de cape et d'œuf de compagnon ne font pas partie de
|
||
ce ticket. La fabrication manuelle et les restrictions natives des machines
|
||
restent applicables. Les interfaces et les transferts sont vérifiés sur la
|
||
cible exacte 26.3-pre-2 avant livraison.
|
||
|
||
## Portage des interfaces
|
||
|
||
Les ressources copiées sans retouche comprennent six fonds personnels et une
|
||
barre rapide, 132 panneaux (22 familles × six hauteurs), 21 fonds supérieurs
|
||
natifs et le cadre de sélection. Les fonds de machines sont redirigés vers le
|
||
namespace Sanctuary uniquement pendant une partie avec progression active.
|
||
Le livre de recettes est conservé et déplacé dans la zone de fabrication.
|
||
|
||
La hauteur visible s'adapte aux conteneurs. Si toutes les rangées ne tiennent
|
||
pas dans un petit GUI, la molette au-dessus du panneau fait défiler les rangées
|
||
de stockage ; la barre rapide reste fixe. Le titre indique les rangées acquises,
|
||
un astérisque signale la récupération d'anciennes cases, et `↕` indique la plage
|
||
visible. Le catalogue créatif garde son protocole de 46 emplacements et propose
|
||
un bouton Inventaire pour ouvrir la vue personnelle, avec les capacités acquises.
|
||
|
||
Les indices internes 36–42 restent réservés à l'équipement Minecraft. L'API
|
||
Inventory adresse les 18 cases supplémentaires par 43–60 ; les indices de menus
|
||
sont distincts et restent ajoutés après les cases natives de chaque conteneur.
|
||
La collecte, le clic de sélection, les ticks d'objets, les recettes et `/clear`
|
||
prennent ces cases en compte. Une recette vérifie la place nécessaire avant de
|
||
restituer sa grille ; les cases verrouillées ne sont pas de la place libre.
|
||
|
||
## Vérifications
|
||
|
||
Contrat écrit avant la modification des données. La commande de livraison est :
|
||
|
||
```sh
|
||
JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
|
||
./gradlew :sanctuary:compileGametestJava check build assemblePack \
|
||
-PsanctuaryFocusedTests=progression,map,demeure,mining,building,inventory
|
||
```
|
||
|
||
**Livraison finale : `check build assemblePack` réussit en 3 min 55 s,
|
||
avec 38 tests natifs réussis**, dont dix scénarios Inventaire. Le journal est
|
||
`build/inventory010-delivery-complete.log`. Les scénarios couvrent les cinq
|
||
achats, la récupération d’anciennes cases, les 54 cases réelles, les outils
|
||
endommagés, les indices de tous les menus enregistrés, les montures, les
|
||
transferts de machines/coffres, les clics et glisser-déposer verrouillés, la
|
||
fabrication manuelle et par recettes, le clic de sélection, `/clear`, la mort,
|
||
`keepInventory` et la relecture des composants depuis la sauvegarde. Les tests purs couvrent aussi les migrations 1–4 → 5, les
|
||
achats et le plafond. La suite native générale de génération n'est pas relancée
|
||
par cette sélection ; ses limites historiques restent documentées séparément.
|
||
|
||
Les sources des tests client compilent avec `-PsanctuaryClientTests=true`.
|
||
Le lancement opt-in `:sanctuary:runClientGameTest -PsanctuaryClientTests=true
|
||
-PsanctuaryInventoryClientTests=true` transforme correctement les classes et
|
||
mixins d'inventaire sur le client natif. Le démarrage graphique reste bloqué dans
|
||
`SDL_GL_SwapWindow` au moment de cet essai : le Mac est verrouillé. Le processus
|
||
de développement a été arrêté après capture des traces. **Aucune capture de
|
||
l'interface ni parcours graphique n'est déclaré validé.** Le scénario client
|
||
préparé ouvre les six capacités et les menus natifs sur plusieurs échelles GUI.
|
||
|
||
Le contrôle de l'archive vérifie les versions internes, les JAR embarqués,
|
||
les textures originales, les libellés FR/EN, les hashes packwiz/Fabric API et
|
||
l'immutabilité des MRpack beta.003–009. Export local uniquement ; aucune
|
||
publication du canal et aucune modification d'instance personnelle.
|
||
|
||
## Revue suivante
|
||
|
||
Vérifier ensemble le rendu, la lecture des rangées et la molette en petit GUI.
|
||
La validation de la progression (PROG-03), le contrat des capacités de faction
|
||
et FACTION-01 restent les étapes suivantes. Ce lot ne crée ni faction, ni
|
||
claim, ni recommencement ; les règles de prestige/charges doivent encore être
|
||
précisées dans CYCLE-01.
|
||
|
||
|
||
## Artefact local vérifié
|
||
|
||
- `build/Sanctuary-beta.010.mrpack` — 2,429,141 octets.
|
||
- SHA-256 : `0d9977227a7204381cebc89b28fa544c64659651bfa0bd400e62dedea1266431`.
|
||
- Reçu de vérification : `build/inventory010-artifact.json`.
|
||
- Les archives beta.003–009 restent strictement identiques.
|