7.2 KiB
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 :
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.