Synchronize verified Sanctuary beta.092 sources and release documentation
Build Sanctuary / build (push) Canceled after 0s
Build Sanctuary / build (push) Canceled after 0s
This commit is contained in:
koka
@@ -0,0 +1,172 @@
|
||||
# ARENA-01 — duels publics, arènes et paris — beta.073
|
||||
|
||||
Branche `codex/familiar-arenas-beta073`. Ticket du 15 septembre 2026.
|
||||
**Implémenté, client natif, compilation et archives locales vérifiés.**
|
||||
|
||||
## Parcours en jeu
|
||||
|
||||
**Pause → Progression → Duels et arènes** ouvre la liste publique. Le même
|
||||
accès figure dans le menu Duel historique. Aucune aptitude de familier ni
|
||||
prestige n'est requis pour organiser un combat entre joueurs.
|
||||
|
||||
1. Créer un **duel** (deux inscrits) ou une **arène** (sans plafond de
|
||||
participants), à l'emplacement de l'organisateur dans sa dimension.
|
||||
2. Choisir **familiers seuls**, **joueurs seuls**, ou **joueurs avec familiers**.
|
||||
Choisir un rayon de 24, 48 ou 96 blocs, une durée de 3, 5 ou 10 minutes,
|
||||
et l'autorisation de la nourriture, des potions et des perles. Les armes,
|
||||
boucliers et munitions restent utilisables. Les familiers gardent leurs
|
||||
statistiques, personnalités, ressources et recharges réelles.
|
||||
3. Choisir l'objet commun dans l'inventaire débloqué, et une mise d'entrée
|
||||
de 0 à 64 objets. Zéro signifie gratuit. Par défaut, l'objet est l'émeraude.
|
||||
Les composants natifs doivent correspondre : un objet renommé ou un
|
||||
contenant rempli n'est pas équivalent à sa version vierge. La création
|
||||
inscrit l'organisateur et prélève sa mise après validation serveur.
|
||||
4. Les autres joueurs consultent les règles, viennent dans le périmètre et
|
||||
s'inscrivent. Chacun valide **Prêt**. Tout changement de la liste invalide
|
||||
les validations. L'organisateur lance quand tous sont présents et prêts.
|
||||
5. **Dix secondes de préparation**, puis chacun pour soi. Les inscriptions
|
||||
et les paris sont fermés dès le lancement de la préparation.
|
||||
|
||||
La liste présente les coordonnées, la dimension, les inscrits, les pots et
|
||||
l'état du combat. Elle contient aussi les duels historiques à invitation,
|
||||
qui gardent leurs deux mises libres et leur double validation. Pour ces seuls
|
||||
duels historiques, le marché des spectateurs utilise des émeraudes ; les mises
|
||||
historiques des deux adversaires restent dans leur menu existant.
|
||||
|
||||
Les annonces d'ouverture, de lancement et de résultat vont dans le chat du
|
||||
serveur. Les combats terminés restent affichés cinq minutes. Les mises dues
|
||||
restent disponibles aussi longtemps que nécessaire. La consultation se fait
|
||||
par pages de douze entrées ; la pagination ne limite pas les inscriptions.
|
||||
Il n'y a ni téléportation de spectateur, ni création automatique de terrain :
|
||||
la carte de playtest se prépare normalement à côté.
|
||||
|
||||
## Combat et règles du monde
|
||||
|
||||
- **Joueurs : morts réelles**, selon le choix du créateur. Aucune santé
|
||||
artificielle à la fin, aucun inventaire restauré par l'arène. Inventaire,
|
||||
perte d'expérience, règles de conservation et tête-tombe suivent Sanctuary
|
||||
et les règles effectives du monde. La mort élimine après le chemin natif
|
||||
de création de la tombe.
|
||||
- **Familiers : K.-O. existant**, santé persistante et récupération habituelle.
|
||||
En mode mixte, le K.-O. du familier laisse son joueur combattre. La mort du
|
||||
joueur élimine son camp. En mode familiers seuls, les propriétaires ne sont
|
||||
pas des cibles et ne frappent pas directement les familiers adverses.
|
||||
- Le dernier camp encore en lice gagne. Abandon, déconnexion pendant le
|
||||
combat, changement d'individu, rappel du familier, sortie du périmètre ou
|
||||
passage en créatif/spectateur éliminent. Le rayon est une distance 3D au
|
||||
centre annoncé : l'altitude compte également.
|
||||
- Une interruption du serveur, un rechargement du catalogue, l'expiration des
|
||||
inscriptions ou une durée écoulée sans vainqueur rembourse les mises.
|
||||
Un joueur déjà éliminé qui se déconnecte ne termine pas le combat des autres.
|
||||
- Avant départ, se désinscrire rembourse son entrée et les paris placés sur
|
||||
soi. Les autres inscriptions restent ouvertes. Le départ de l'organisateur
|
||||
annule l'événement entier. Les duels historiques gardent leur contrat
|
||||
d'interruption/refund antérieur.
|
||||
- La permission PvP du combat ne vise que les adversaires inscrits en lice,
|
||||
même si le PvP général est désactivé ou s'ils sont de la même faction.
|
||||
Les dégâts directs ne franchissent pas cette frontière ; les familiers
|
||||
hors combat n'apportent pas leur assistance aux combattants.
|
||||
- Pose, utilisation et casse de blocs par les combattants sont désactivées,
|
||||
y compris les gestes de minage/construction groupés déjà commencés.
|
||||
Cela ne transforme pas le périmètre en claim : les mécanismes du monde,
|
||||
cosmétiques, pièges ou interventions d'opérateurs restent ceux de la map.
|
||||
|
||||
## Paris en objets
|
||||
|
||||
La mise d'inscription est identique pour tous ; son pot revient au vainqueur.
|
||||
Les spectateurs choisissent un inscrit et déposent une quantité libre de
|
||||
l'objet commun, jusqu'à 3 456 unités par geste et dans la limite de leur
|
||||
inventaire débloqué. Plusieurs gestes sont possibles avant le lancement.
|
||||
Il n'y a pas de commission.
|
||||
|
||||
Le pot des spectateurs est partagé **au prorata des mises gagnantes**. Les
|
||||
unités indivisibles restantes sont réparties dans l'ordre stable des UUID.
|
||||
Exemple : 4 objets sur A, 2 autres sur A et 3 sur B ; si A gagne, les deux
|
||||
parieurs gagnants récupèrent respectivement 6 et 3 objets. Si personne n'avait
|
||||
misé sur le vainqueur, les paris sont remboursés.
|
||||
|
||||
Un inscrit ne peut pas parier sur son combat. Un parieur ne peut plus s'y
|
||||
inscrire. Les boutons utilisent des identifiants et des révisions contrôlés
|
||||
par le serveur ; aucune pile fournie par le client ne sert de preuve de fonds.
|
||||
Les fonds sont pris uniquement dans les rangées réellement débloquées.
|
||||
|
||||
Les gains se récupèrent dans **Duels et arènes**. Un inventaire plein conserve
|
||||
le solde dans le registre ; libérer même une partie d'une pile permet de le
|
||||
récupérer progressivement. Aucun paiement ne tombe au sol et un joueur mort
|
||||
ne peut pas encaisser dans l'inventaire en cours de remplacement.
|
||||
|
||||
## Contrat de sauvegarde additif
|
||||
|
||||
Aucun registre historique, identifiant d'objet, génération ou monde personnel
|
||||
n'est converti. Nouveau fichier séparé :
|
||||
`sanctuary/arena-stakes-v1.json`, schéma 1. Nouveau reçu joueur persistant et
|
||||
copié à la mort : `sanctuary:arena_receipt`.
|
||||
|
||||
Chaque dépôt est écrit avant le débit, puis l'inventaire natif et son reçu sont
|
||||
sauvegardés ensemble dans `playerdata` et relus. Le journal confirme ensuite
|
||||
le débit. Chaque résultat répartit la totalité des fonds en une écriture
|
||||
atomique avant le paiement. Chaque paiement sauvegarde de même l'inventaire
|
||||
et son reçu avant de retirer la dette du journal. Une collecte partielle garde
|
||||
le reste et ne repaie pas une tranche déjà reçue.
|
||||
|
||||
Au redémarrage, les combats vivants ne reprennent pas : les mises réellement
|
||||
débitées sont remboursées. Un résultat déjà réparti conserve ses destinataires.
|
||||
Les dépôts inachevés sont résolus à la reconnexion du payeur d'après son reçu,
|
||||
sans inventer de crédit. Une erreur disque, un schéma inconnu ou un journal
|
||||
invalide préserve les fichiers et suspend les transactions.
|
||||
|
||||
Le journal a une borne de lecture/écriture de 32 Mio pour détecter les états
|
||||
anormaux. C'est une limite de stockage des opérations en attente, pas un nombre
|
||||
maximum de participants. Avant un retour à une ancienne version, terminer
|
||||
les événements et récupérer les soldes ; sinon restaurer une sauvegarde
|
||||
complète cohérente, jamais un seul registre ou un seul fichier joueur.
|
||||
|
||||
## Vérifications et limites
|
||||
|
||||
Minecraft **26.3-pre-2**, Java 25, Fabric API **0.160.0+26.3**.
|
||||
`Arena073ClientChecks` utilise un client intégré et des joueurs serveur
|
||||
synthétiques avec connexions natives, dans un monde plat de développement.
|
||||
Aucun serveur personnel ni EULA de serveur dédié n'est modifié.
|
||||
|
||||
La validation couvre trois familiers en combat autonome, des joueurs avec
|
||||
morts réelles, le mode mixte, les permissions PvP, les paris, le partage exact,
|
||||
les remboursements, l'inventaire plein et les composants de contenants. Une
|
||||
arène de 25 inscrits vérifie la pagination sans plafond de participants.
|
||||
Les menus FR/EN et l'aller-retour réseau du bouton de création sont contrôlés.
|
||||
Résultat client : **réussi**, `ARENA073_PASS`, 1 min 52 s. Les tests
|
||||
`Duel054Checks` sont rejoués dans la même session : validation mutuelle, anciennes
|
||||
mises, projectiles natifs, K.-O., refus d’un projectile tardif et remboursements
|
||||
passent aussi. La mort pendant les inscriptions libère l’inscription sans
|
||||
annuler les autres. Le journal est éprouvé avant débit, après sauvegarde du
|
||||
débit, après sauvegarde du paiement et avec un schéma inconnu. Les essais
|
||||
conservent les quantités exactes et refusent le schéma inconnu sans réécriture.
|
||||
|
||||
Journal client : `build/arena073-workspace/build/arena073-client.log`.
|
||||
Captures copiées dans `build/arena073-evidence/`.
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
réussit en **2 min 56 s**, 124 tâches (108 exécutées). Les GameTests serveur
|
||||
dédiés sont exclus conformément au refus d'accepter leur EULA ; les scénarios
|
||||
multijoueurs de ce ticket tournent dans le serveur intégré du client natif.
|
||||
|
||||
Les **1 689 classes** compilées, les ressources et les sources Java correspondent
|
||||
aux archives. Par rapport à beta.072, seules les classes de ce ticket et les
|
||||
métadonnées de version évoluent ; les ressources existantes, les 88 profils et
|
||||
le resource pack beta.070 restent identiques. Les **79 nouvelles clés FR/EN**
|
||||
sont présentes dans les deux langues. Les archives beta.070 à beta.072 restent
|
||||
inchangées.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.073.mrpack) : 9 592 283 octets.
|
||||
- [Pack Test, monde plat rapide](../build/Sanctuary-Test-beta.073.mrpack) :
|
||||
9 611 218 octets.
|
||||
- [Reçu des artefacts et SHA-256](../build/arena073-artifact.json).
|
||||
|
||||
La livraison a été construite dans `build/arena073-workspace`, copie isolée
|
||||
incluant la version beta.072 vérifiée, puis les seuls changements de ce ticket
|
||||
ont été réintégrés dans les sources partagées. Aucun canal distant, serveur
|
||||
personnel ou instance Prism n'est mis à jour.
|
||||
|
||||
Ce ticket fournit un outil de playtest. Il ne constitue pas une validation
|
||||
exhaustive de l'équilibrage des 88 espèces, un benchmark de très grand serveur,
|
||||
ni une protection compétitive contre les complicités et abandons arrangés.
|
||||
Les tests de reprise ne simulent pas une panne physique du disque.
|
||||
+160
@@ -1,5 +1,159 @@
|
||||
# Backlog Sanctuary
|
||||
|
||||
## SKY-077 — tourbillon au-dessus du vide
|
||||
|
||||
Branche `codex/cloud-vortex-beta077`. [Ticket](cloud-vortex-beta077.md).
|
||||
Couche native à Y = 0, diamètre double de l’île, rotation et géométrie en cache.
|
||||
Livraison groupée avec les correctifs de menus beta.076. Tests natifs, cache,
|
||||
transparence Fabulous, build et archives normal/Test vérifiés.
|
||||
|
||||
## UI-076 — navigation et pouvoirs sélectionnés
|
||||
|
||||
Branche `codex/menu-navigation-beta076`. [Ticket](menu-navigation-beta076.md).
|
||||
Accès direct aux combats depuis Pause, parcours prestige/faction/historique,
|
||||
achats visibles et sélection du pouvoir utilitaire explicite. Parcours natif vérifié ;
|
||||
distribution regroupée avec beta.077.
|
||||
|
||||
## PLAN-FIX-01 — retirer la recherche web (beta.075)
|
||||
|
||||
Branche `codex/plans-library-beta075`. [Correctif](plans-library-beta075.md).
|
||||
Retirer le bouton Minecraft Schematics de K → Bibliothèque et ses libellés.
|
||||
Build, sources et archives normal/Test vérifiés ; anciens packs conservés.
|
||||
|
||||
## FAMILIAR-05 — autonomie et ordres rapides (beta.074)
|
||||
|
||||
Branche `codex/familiar-autonomy-beta074`. [Contrat](familiar-autonomy-beta074.md).
|
||||
Quatre règles de comportement distinctes, garde locale, sélection des menaces,
|
||||
retour après poursuite, gestion des cibles inaccessibles et H bref/maintenu.
|
||||
Parcours natif, régressions montures/arènes/duels et `check build` réussis.
|
||||
Archives normal/Test vérifiées ; textures beta.070 conservées.
|
||||
|
||||
## PLAN-01 — statues et plans natifs (beta.072)
|
||||
|
||||
Branche `codex/statues-plans-beta072`.
|
||||
[Contrat, formats et vérifications](statues-plans-beta072.md). Modèles et textures
|
||||
du jeu convertis en statues creuses ; bibliothèque compatible `.litematic`,
|
||||
`.schem` v2/v3 et `.nbt`, aperçu par couche, rotation, matériaux et collage
|
||||
créatif contrôlé côté serveur. En survie, construction manuelle native.
|
||||
Aucune dépendance Litematica/MaLiLib ajoutée.
|
||||
Capture native des 88 espèces, parcours creeper créatif/survie FR/EN,
|
||||
interopérabilité Litemapy, sept tests serveur et 130 tâches Gradle réussis.
|
||||
Archives normal/Test vérifiées ; anciennes `.schematic` à convertir en externe.
|
||||
|
||||
## MB-01 — Reprendre le catalogue des multiblocs
|
||||
|
||||
**Ticket local ouvert le 15 septembre 2026 ; premier lot implémenté en beta.084.**
|
||||
[Catalogue et décisions historiques](multiblocs-conception.md) ·
|
||||
[Ticket de cadrage et lots d'implémentation proposés](multiblocs-ticket.md).
|
||||
Branche documentaire réservée `codex/multiblocs-ticket`.
|
||||
|
||||
Premier lot choisi le 16 septembre 2026 : **clé dorée, Fourneau et Fût**,
|
||||
implémenté en [beta.084](multiblocs-beta084.md) sur `codex/multiblocs-beta084`. Fermentation, présentoirs,
|
||||
méga-pistons, Trémie, Carillon et Métablit restent au catalogue.
|
||||
La clé dorée assemble volontairement et dissocie ; les composants restent
|
||||
indépendants à la pose. Le Fût à 729 cases avec recherche et pages est accepté.
|
||||
Les gestes et la chauffe du premier lot sont décrits dans sa livraison. La fusion de tout
|
||||
It's Alive dans Sanctuary est différée ; le Fourneau pourrait alors remplacer
|
||||
la cuisinière, selon le [cadrage corrigé](multiblocs-itsalive-contrat.md).
|
||||
Aucun nouveau multibloc ni binaire livré ici.
|
||||
Les huit candidats de la [recherche complémentaire](multiblocs-recherche.md)
|
||||
sont rejetés par le créateur, jugés sans intérêt ou contraires au contrat
|
||||
Minecraft Vanilla. Reprendre le catalogue antérieur pour la liste d'implémentation.
|
||||
|
||||
## FAMILIAR-04 — personnalité et montures natives (beta.071)
|
||||
|
||||
Branche de départ `codex/familiar-personality-beta071`.
|
||||
[Contrat et vérifications](familiar-personality-beta071.md). Quatre caractères
|
||||
stables avec tendances d’espèce ; priorité des ordres, poursuite plus vive et
|
||||
verrouillage de combat conservé. Escalade des deux araignées, Souffle du
|
||||
Nautilus pour les deux variantes colossales et surface de lave du Strider.
|
||||
Audit des 14 espèces montables natives, parcours client et 124 tâches Gradle
|
||||
réussis ; archives isolées de la beta.072 en cours, resource pack beta.070.
|
||||
|
||||
## RP-02 — textures versionnées et actives par défaut (beta.070)
|
||||
|
||||
Branche `codex/resourcepack-beta070`.
|
||||
[Contrat et vérifications](resourcepack-beta070.md). Import des dessins fournis,
|
||||
source et manifeste d’empreintes enregistrés dans Git ; pack natif activé par
|
||||
défaut et désactivable. Sept textures de faim/saturation mises à jour, respiration
|
||||
vanilla conservée. Client natif, build, deux MRpacks et ZIP autonome vérifiés.
|
||||
|
||||
## FAMILIAR-FIX-02 — retour des ordres sur H (beta.069)
|
||||
|
||||
Branche `codex/familiar-orders-h-beta069`.
|
||||
[Contrat et tests](familiar-orders-beta069.md). H pour les ordres, F pour
|
||||
l’échange des mains, G pour la technique. Conversion unique de l’ancien
|
||||
raccourci F en H ; suppression du filtrage de l’échange natif. Parcours
|
||||
client et compilation vérifiés, deux archives locales conformes.
|
||||
|
||||
## LOAD-03 — animation discrète de l’attente (beta.068)
|
||||
|
||||
Branche `codex/loading-animation-beta068`.
|
||||
[Résultat et vérifications](loading-animation-beta068.md) : neuf glyphes SGA
|
||||
avec une lumière mobile, animés par l’horloge de rendu ; étapes réelles et
|
||||
carte des chunks conservées. Huit captures natives comparées, FR/EN inspectés,
|
||||
compilation et archives normal/Test vérifiées. Introduction et cache inchangés.
|
||||
|
||||
## FAMILIAR-FIX-01 — touche et vol du dragon (beta.067)
|
||||
|
||||
Branche `codex/familiar-controls-beta067`.
|
||||
[Contrat et vérifications](familiar-controls-beta067.md) : ordres sur F,
|
||||
remappage unique de l'ancien H et prévention du double déclenchement de
|
||||
l'échange des mains ; orientation du dragon corrigée. Plané des petits
|
||||
vérifié, montée du grand porté avec Espace et monture colossale vérifiées.
|
||||
Compilation et deux archives validées localement.
|
||||
|
||||
## HEAD-FIX-01 — modèles animés superposés (beta.066)
|
||||
|
||||
Branche `codex/cosmetic-render-beta066`.
|
||||
[Résultat et tests](head-render-beta066.md). Doublon de coffre reproduit dans
|
||||
le collecteur natif puis corrigé ; une seule cloche animée avec son support.
|
||||
Ouvertures/fermetures, aliments, autres modèles et douze cas sur des mobs
|
||||
adultes ou bébés vérifiés. Build et archives validés localement.
|
||||
|
||||
## BOAT-FIX-01 — collisions des coques (beta.065)
|
||||
|
||||
Branche `codex/boat-collisions-beta065`.
|
||||
[Résultat et tests](boat-collisions-beta065.md) : coque entière couverte,
|
||||
virages contrôlés avant la translation, recul conservé. Passage au travers
|
||||
des murs reproduit puis corrigé ; 88 variantes et seize parcours pilotés
|
||||
vérifiés en client natif et serveur intégré. Build et deux archives validés
|
||||
localement ; pas de déploiement personnel.
|
||||
|
||||
## LOAD-02 — cache et étapes réelles de préchargement (beta.064)
|
||||
|
||||
Branche `codex/loading-cache-beta064`.
|
||||
[Contrat, mesures et vérifications](loading-cache-beta064.md). Plans dérivés
|
||||
mis en cache sur disque, validation des données et recalcul automatique si
|
||||
une entrée manque ou est corrompue. Réouverture mesurée à 2,1 s contre 58,7 s
|
||||
lors de l’audit beta.063 ; première création à 122 s, introduction complète.
|
||||
Étapes réelles du serveur, écran natif épuré sans portail du Nether. Pas de
|
||||
migration des chunks ou des journaux d’expansion. Build, récupération d’un cache
|
||||
corrompu, huit ouvertures classiques/plates et archives vérifiés localement.
|
||||
|
||||
## RP-HUD-01 — base de textures modifiable
|
||||
|
||||
**Préparée le 15 septembre 2026**, branche `codex/resourcepack-hud-base`.
|
||||
[Résultat et vérifications](resourcepack-hud-base.md) : 53 sprites vanilla
|
||||
de vie et de faim, manifeste 26.3-pre-2 et guide de retouche FR/EN dans le
|
||||
resource pack Sanctuary existant. Les dessins seront modifiés par le créateur.
|
||||
Ce lot graphique séparé ne livre pas de nouveau binaire du mod.
|
||||
|
||||
## CAPE-01 — Des capes rares aux pouvoirs durables
|
||||
|
||||
**Ticket préparé le 15 septembre 2026 ; à arbitrer puis à implémenter.**
|
||||
[Intention, premier lot proposé et critères d'acceptation](capes-gameplay.md).
|
||||
Branche documentaire réservée `codex/capes-ticket` ; branche d'implémentation
|
||||
prévue `codex/capes-gameplay`.
|
||||
|
||||
Les capes apportent généralement un bonus passif permanent, proposé tant
|
||||
qu'elles sont portées. Des capes très puissantes restent possibles, avec rareté,
|
||||
contreparties ou périodes actives à éprouver selon leur impact. Le ticket
|
||||
prépare trois capes aux usages distincts, leur acquisition rare en survie et
|
||||
les essais de cumuls, de circulation et de progression. Catalogue, valeurs,
|
||||
malus et règles temporelles restent des propositions. Cape Zéro est actuellement
|
||||
visuelle ; aucun nouveau pouvoir ni changement de binaire livré par ce ticket.
|
||||
|
||||
## ANO-01 — Les doubles de Steve
|
||||
|
||||
**Conception du 15 septembre 2026 ; non implémentée.**
|
||||
@@ -1566,3 +1720,9 @@ secrets et traversées. Comparer les champs natifs 27, 30.1, 30.4 et 30.5 par
|
||||
coupes et cartes scientifiques, archivées avec leurs sources et leurs graines.
|
||||
Les expéditions anciennes et les îles supérieures ciblées restent à définir.
|
||||
Voir [la génération](generation-alpha30.5.md) et [l’atlas](terrain-atlas.md).
|
||||
|
||||
## ARENA-01 — beta.073 — duels publics et arènes
|
||||
|
||||
Livré et vérifié : trois modes de combat, inscriptions sans plafond pour les arènes,
|
||||
paris en objets, annonces et liste publique. Joueurs avec morts réelles.
|
||||
[Contrat et essais](arenas-beta073.md).
|
||||
|
||||
@@ -0,0 +1,100 @@
|
||||
# beta.065 — collisions des bateaux collectifs
|
||||
|
||||
Branche `codex/boat-collisions-beta065`.
|
||||
|
||||
## Problème et portée
|
||||
|
||||
Les huit formes de bateaux et radeaux collectifs utilisent le déplacement natif
|
||||
côté serveur. Leurs anciennes limites étaient fondées sur une tuile carrée de
|
||||
1,375 bloc, alors que les modèles ont une longueur de 28 pixels par module.
|
||||
La coque visible dépassait donc sa collision dans le sens longitudinal. Un
|
||||
virage agrandissait aussi directement les limites sans vérifier le terrain ;
|
||||
après cette intrusion, le déplacement natif pouvait traverser le mur.
|
||||
|
||||
Les limites couvrent désormais les coques complètes, et le volume balayé
|
||||
par chaque virage est contrôlé avant le déplacement. Le mouvement natif reste utilisé pour
|
||||
les translations, l’appui au sol et sur l’eau, les formes de blocs et les
|
||||
collisions avec les autres véhicules. Les sièges, les commandes partagées,
|
||||
les moteurs, les vitesses et les règles de chute des piles restent inchangés.
|
||||
|
||||
Les modèles et les textures ne changent pas. Les bateaux simples Minecraft
|
||||
conservent leur comportement. Aucune modification de chunk, de recette, de
|
||||
journal ou de format de sauvegarde ; les identifiants existants restent stables.
|
||||
Les positions enregistrées des anciens bateaux ne sont pas déplacées par la
|
||||
mise à jour : seule leur collision utilise les dimensions corrigées.
|
||||
|
||||
## Collision de la coque
|
||||
|
||||
Les huit formes sont couvertes : 1 × 2, 2 × 1, 1 × 3, 3 × 1, 2 × 2,
|
||||
2 × 3, 3 × 2 et 3 × 3, sur les onze bois. Largeur et longueur de la coque :
|
||||
|
||||
- Bois : `colonnes + 0,25` × `rangées × 1,75 + 0,25` blocs, rebords compris.
|
||||
- Bambou : `colonnes × 1,25` × `rangées × 1,75` blocs.
|
||||
|
||||
Comme dans le moteur natif, la collision est une boîte alignée sur les axes ;
|
||||
elle englobe la coque orientée. Les rames animées restent décoratives. Un virage
|
||||
vérifie aussi les extrema entre ses deux orientations, pour qu’un coin ne
|
||||
traverse pas un mur avant de revenir dans une position libre. Au contact,
|
||||
l’inertie de rotation s’arrête ; le recul et le glissement le long du mur restent
|
||||
résolus par Minecraft. Les rotations de placement ou de téléportation ne sont
|
||||
pas remplacées par des tentatives de conduite.
|
||||
|
||||
## Vérification
|
||||
|
||||
Client Minecraft 26.3-pre-2 et serveur intégré de développement, monde plat
|
||||
neuf de graine `65`. Le test avant correction traverse effectivement le mur
|
||||
situé en X=8 : après quinze mouvements avec virage, le centre atteint X=12,55.
|
||||
Ce même cas passe après correction.
|
||||
|
||||
- **88 variantes** : **3 168 déplacements** contre des murs dans les deux sens
|
||||
de X et Z, huit orientations, diagonales et déplacements de vingt blocs en
|
||||
un appel ; collision native détectée et recul libre de 1,5 bloc.
|
||||
- **440 virages** : contact et tentative de déplacement dans le mur, virages
|
||||
libres, puis cas où les orientations de départ et d’arrivée sont libres
|
||||
mais où le milieu du virage heurterait le mur. Ce dernier cas est refusé.
|
||||
- **128 passages** contre les formes natives minces des barrières et vitres,
|
||||
sur bateaux et radeaux, sans traversée ni recouvrement des blocs.
|
||||
- **704 modèles orientés** : les sommets réels des fonds et rebords sont inclus
|
||||
dans les collisions, côté client. Les rames sont explicitement exclues.
|
||||
- **16 parcours pilotés avec les vraies touches**, huit formes en chêne et en
|
||||
bambou, répartis entre eau et vol avec Allay et les quatre directions :
|
||||
avancer contre le mur, maintenir le virage, reculer. Les limites serveur et
|
||||
client restent à l’intérieur des murs, le pilote reste assis et le recul
|
||||
déplace effectivement le bateau. Deux captures de contact ont été relues.
|
||||
|
||||
Journaux locaux : `build/boat065-before.log`,
|
||||
`build/boat065-control-before.log`, `build/boat065-fixed-probe.log`,
|
||||
`build/boat065-client.log`. Captures : `build/boat065-evidence/`.
|
||||
Le parcours complet passe en **1 min 59 s**.
|
||||
|
||||
```sh
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryBoat065ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Les essais utilisent le serveur intégré ; aucun serveur dédié ni EULA acceptée.
|
||||
Le test client couvre la synchronisation locale ; une session avec plusieurs
|
||||
clients distants et latence n’a pas été relancée pour ce correctif.
|
||||
|
||||
## Livraison locale
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack` réussi en **2 min 8 s**,
|
||||
**122 tâches**, avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true`. Les essais serveur intégrés ci-dessus remplacent
|
||||
les tests dédiés exclus conformément au refus antérieur d’accepter leur EULA.
|
||||
|
||||
Les archives normal/Test sont vérifiées : **1 645 classes** conformes à la
|
||||
compilation, aucune classe de test embarquée, mêmes ressources et dépendances
|
||||
qu’en beta.064. Seule la source principale `CrewBoat` change, en plus des
|
||||
métadonnées de version. Modèles, textures, recettes, sièges, moteurs et autres
|
||||
systèmes restent conservés. Les anciennes archives beta.064 sont intactes.
|
||||
|
||||
|
||||
- [Pack normal beta.065](../build/Sanctuary-beta.065.mrpack), 5721084 octets.
|
||||
SHA-256 : `71ff1736817e2953f88a8afda5858b2e7ae23c360efdb7e25f149cbff049d764`.
|
||||
- [Monde plat rapide beta.065](../build/Sanctuary-Test-beta.065.mrpack), 5740018 octets.
|
||||
SHA-256 : `4c4931146a05d6f57e9abf2303b039ab7a7bc16471a0b864873b86bef297431d`.
|
||||
|
||||
Reçu `build/boat065-artifact.json`, build `build/boat065-check.log`.
|
||||
Aucun canal publié, instance Prism ou monde personnel modifié.
|
||||
@@ -0,0 +1,74 @@
|
||||
# beta.091 — Interagir avec les animaux embarqués
|
||||
|
||||
Branche `codex/boat-passenger-interactions-beta091`, Minecraft 26.3.
|
||||
|
||||
## Contrat
|
||||
|
||||
Depuis un bateau, viser un mob directement installé sur un siège permet les
|
||||
interactions habituelles : clic gauche pour le frapper, clic droit pour utiliser
|
||||
son objet de tête ou son interaction native. Cela couvre les bateaux/radeaux
|
||||
Minecraft et tous les formats Sanctuary. Les coups sur les animaux ordinaires
|
||||
infligent leurs dégâts habituels ; les familiers conservent leur réaction sans
|
||||
blessure hors des combats prévus, avec déclenchement de leur équipement.
|
||||
|
||||
Le ciblage natif excluait les entités partageant le véhicule racine du joueur.
|
||||
L'exception est limitée au curseur du joueur et aux mobs assis directement dans
|
||||
son bateau. Portée, obstacles et choix de la cible la plus proche restent ceux
|
||||
de Minecraft. Les collisions des projectiles ne sont pas modifiées.
|
||||
|
||||
Le bateau limite aussi normalement le regard à ±105 degrés. Avec un mob à bord,
|
||||
les joueurs peuvent désormais regarder autour d’eux à 360 degrés, notamment
|
||||
vers le siège arrière. Les commandes de déplacement et la rotation du bateau
|
||||
restent indépendantes du regard ; les mobs gardent leur orientation native.
|
||||
|
||||
La protection de portage des familiers distingue désormais un siège de bateau
|
||||
d'un familier porté sur la tête ou monté. Les protections entre joueurs portés
|
||||
restent en place. Les dégâts et interactions continuent à être validés côté
|
||||
serveur ; aucun nouveau paquet, inventaire, identifiant ou format de sauvegarde.
|
||||
Aucune modification des mondes existants ni de la génération.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Le parcours `BoatPassengers091ClientChecks` crée un monde plat de développement,
|
||||
graine 42, et utilise le curseur natif et les vrais clics souris. Il teste un
|
||||
coffre porté puis un distributeur chargé sur une poule embarquée.
|
||||
|
||||
Le parcours natif passe en **1 min 13 s** sur Minecraft 26.3/macOS :
|
||||
|
||||
- 13 cas : bateau et radeau vanilla, les huit formats Sanctuary, radeau 3 × 3,
|
||||
poule bébé et familier installé comme passager pour vérifier sa protection.
|
||||
- Vrai ciblage du corps depuis le siège, y compris vers l’arrière ; aucun
|
||||
remplacement artificiel du résultat de visée dans le test.
|
||||
- Clic droit : ouverture du coffre natif contenant les sept diamants attendus.
|
||||
- Clic gauche : perte de vie de la poule, une flèche consommée et un projectile
|
||||
réel créé par le distributeur, sans éjection de l’animal.
|
||||
- Familier : même tir au toucher, vie inchangée. Une fois porté sur la tête,
|
||||
protection symétrique conservée et aucun nouveau déclenchement au toucher.
|
||||
|
||||
```sh
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryBoatPassengers091ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Journal : `build/boat091-client.log`, marqueur `BOAT091_PASS`.
|
||||
|
||||
## Livraison
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
passe en **2 min 20 s**, 124 tâches. Journal : `build/boat091-check.log`.
|
||||
Les deux exports sont vérifiés contre les JAR et leurs sources. Les textures,
|
||||
modèles, données et JEI restent identiques à beta.090 ; ses archives sont intactes.
|
||||
Le reçu local est `build/boat091-artifact.json`.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.091.mrpack), SHA-256
|
||||
`0d0e847e5b8f22637b6e280d0694ab5a2cdb8cb01a47442d92c5103e3e3f53ac`.
|
||||
- [Pack Test](../build/Sanctuary-Test-beta.091.mrpack), SHA-256
|
||||
`392773b8e5fc8948cdb5ea9cd7e8cc8cd97ed43bdc5fe413fef32b05758f8edc`.
|
||||
|
||||
## Limites
|
||||
|
||||
Les essais utilisent un client natif et son serveur intégré de développement ;
|
||||
pas de session LAN à deux clients pour cette livraison. Les tests dédiés restent
|
||||
exclus et aucune EULA n’est acceptée. Aucun déploiement dans une instance
|
||||
personnelle ni publication du canal packwiz.
|
||||
@@ -0,0 +1,85 @@
|
||||
# beta.080 — portée de Construction et progression de Minage
|
||||
|
||||
Branche `codex/build-mining-balance-beta080`, Minecraft 26.3-pre-2, textures beta.070.
|
||||
|
||||
Construction augmente la distance de pose. Minage augmente indépendamment
|
||||
la distance et la vitesse de casse. Le départ est inférieur au vanilla ;
|
||||
les derniers paliers le dépassent modérément. Les coûts, sept achats par
|
||||
compétence et tailles des groupes restent ceux du système existant.
|
||||
|
||||
| Rang | Vitesse de minage, référence vanilla | Portée de minage | Portée de pose |
|
||||
| --- | --- | --- | --- |
|
||||
| 0 | 75 % | 3 blocs | 3 blocs |
|
||||
| 1 | 85 % | 3,5 blocs | 3,5 blocs |
|
||||
| 2 | 95 % | 4 blocs | 4 blocs |
|
||||
| 3 | 100 % | 4,5 blocs | 4,5 blocs |
|
||||
| 4 | 107,5 % | 4,75 blocs | 4,75 blocs |
|
||||
| 5 | 115 % | 5 blocs | 5 blocs |
|
||||
| 6 | 122,5 % | 5,25 blocs | 5,25 blocs |
|
||||
| 7 | 130 % | 5,5 blocs | 5,5 blocs |
|
||||
|
||||
Chaque colonne dépend de sa propre compétence. La vitesse s’applique via
|
||||
l’attribut natif de casse, avec les outils, enchantements et autres effets.
|
||||
Les portées préservent les bonus externes de l’attribut d’interaction ;
|
||||
les valeurs du tableau supposent cet attribut à sa valeur survival de base.
|
||||
Créatif, spectateur et joueurs sans progression Sanctuary conservent leur
|
||||
portée native. Les infobulles FR/EN affichent le palier actuel et le suivant.
|
||||
|
||||
La visée peut sélectionner le plus éloigné des gestes disponibles ; les
|
||||
validations de chaque action appliquent ensuite sa propre portée. Ainsi,
|
||||
voir le contour d’un bloc n’accorde pas forcément la portée pour le miner
|
||||
ou y poser un bloc : le même contour sert aux interactions ordinaires.
|
||||
La portée des coffres, autres interactions et attaques n’augmente pas.
|
||||
Un coffre hors de portée native peut servir de support de construction,
|
||||
sans s’ouvrir à distance. La main gauche et les plantes aquatiques suivent
|
||||
la portée de Construction.
|
||||
|
||||
Les deux sélections groupées vérifient leur ancre avec leur compétence.
|
||||
Le plan et la veine verrouillés conservent leur contrat : les cellules du
|
||||
groupe peuvent dépasser la portée de l’ancre. Les droits, protections,
|
||||
collisions, stock, conditions de pose et chunks chargés restent vérifiés.
|
||||
La validation réseau conserve la tolérance native de distance à l’entrée
|
||||
des paquets ; la pose vérifie aussi la distance du point cliqué côté serveur.
|
||||
|
||||
Aucun identifiant, schéma de sauvegarde ni terrain modifié. Les anciens
|
||||
rangs reçoivent les nouvelles valeurs à leur application habituelle ; un
|
||||
reset ou prestige revient aux valeurs de départ.
|
||||
|
||||
## Vérification
|
||||
|
||||
`Balance080ClientChecks` réussit en **1 min 03 s**, dans un monde plat solo
|
||||
jetable, avec les gestes natifs et les paquets réels client/serveur :
|
||||
|
||||
- Les huit rangs, vitesse native de casse d’un bloc et composition des bonus.
|
||||
- Pose proche au rang zéro, refus de la pose lointaine sans perte de stock.
|
||||
- Minage et pose au-delà de la portée vanilla ; indépendance des deux compétences.
|
||||
- Pose en main gauche et refus serveur d’un paquet visant trop loin.
|
||||
- Coffre lointain utilisable comme support sans ouvrir son inventaire ; un
|
||||
briquet en main principale ne profite pas de la portée du bloc en main gauche.
|
||||
- Construction d’un plan complet de neuf blocs à la nouvelle portée.
|
||||
- Vein mining de neuf blocs à cette portée, regard détourné après verrouillage.
|
||||
- Pose d’un nénuphar, retour aux rangs zéro, créatif et joueur sans progression.
|
||||
|
||||
Journal : `build/balance080-client.log`. Les interactions des blocs portés
|
||||
sur la tête ont également été relues : elles passent par leur contexte
|
||||
propre, sans la pose de bloc interceptée ici.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en **2 min 27 s**,
|
||||
124 tâches (104 exécutées, 20 à jour), avec `-x :sanctuary:runGameTest`.
|
||||
Journal : `build/balance080-check.log`.
|
||||
|
||||
Les **1 700 classes** du JAR correspondent aux fichiers compilés. Les 17
|
||||
classes ajoutées ou modifiées par rapport à beta.079 concernent uniquement
|
||||
ce ticket ; quatre libellés évoluent par langue. Sources et ressources
|
||||
vérifiées, textures beta.070 identiques, même JAR intégré aux deux packs.
|
||||
Les archives beta.079 sont conservées à l’identique.
|
||||
Reçu : `build/balance080-artifact.json`. Aucun déploiement personnel.
|
||||
Le serveur dédié reste exclu conformément au refus de son EULA ; le test
|
||||
natif ci-dessus utilise le serveur intégré.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.080.mrpack](../build/Sanctuary-beta.080.mrpack).
|
||||
SHA-256 : `feb20b882442149789ed6d90e32073aa6201314a57782105a0330394c76e796d`.
|
||||
- [Sanctuary-Test-beta.080.mrpack](../build/Sanctuary-Test-beta.080.mrpack).
|
||||
SHA-256 : `fc277f081f160ae8ae835501cddddd572cdffe4749454e1652a080a117bfb941`.
|
||||
@@ -0,0 +1,43 @@
|
||||
# beta.081 — portée de pose jusqu’à six blocs
|
||||
|
||||
Branche `codex/build-reach-six-beta081`, Minecraft 26.3-pre-2, textures beta.070.
|
||||
|
||||
À la demande du joueur, Construction atteint maintenant **six blocs**.
|
||||
Les portées des rangs 0 à 7 sont : **3 ; 3,5 ; 4 ; 4,5 ; 4,75 ; 5 ; 5,5 ; 6**.
|
||||
Le rang 6 est également ajusté pour terminer par deux gains d’un demi-bloc.
|
||||
La référence reste l’attribut d’interaction vanilla sans bonus externe.
|
||||
|
||||
Le minage conserve sa portée maximale de 5,5 blocs et sa vitesse de 130 %.
|
||||
Le contrat client/serveur, la pose en main gauche, les plans groupés et les
|
||||
infobulles FR/EN utilisent déjà la même source des valeurs. Aucun changement
|
||||
des coûts, identifiants, sauvegardes ou mondes ; les archives beta.080 restent
|
||||
immuables.
|
||||
|
||||
## Vérification
|
||||
|
||||
Le scénario natif `Balance080ClientChecks`, ajusté à cette courbe, réussit
|
||||
en **1 min 21 s** dans un monde solo jetable : pose réelle à 5,75 blocs,
|
||||
refus serveur d’un clic à 6,25 blocs sans perte de stock, et régression des
|
||||
huit rangs, du minage indépendant, de la main gauche, des groupes, des
|
||||
nénuphars, du créatif et des bonus externes.
|
||||
Journal : `build/reach081-client.log`.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en **2 min 30 s**,
|
||||
124 tâches (103 exécutées, 21 à jour), avec `-x :sanctuary:runGameTest`.
|
||||
Journal : `build/reach081-check.log`.
|
||||
|
||||
Les 1 700 classes et les sources correspondent aux fichiers compilés :
|
||||
seule `BuildingLimits` change par rapport à beta.080. Ressources et textures
|
||||
identiques, même JAR dans les deux packs, archives beta.080 préservées.
|
||||
Reçu : `build/reach081-artifact.json`.
|
||||
|
||||
Le serveur dédié reste exclu
|
||||
conformément au refus de son EULA ; le test utilise le serveur intégré.
|
||||
Aucun déploiement personnel.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.081.mrpack](../build/Sanctuary-beta.081.mrpack).
|
||||
SHA-256 : `7f789522eaa4a2574cc9bee4a4def7862a4893c8f462e88502ca858440c8ee02`.
|
||||
- [Sanctuary-Test-beta.081.mrpack](../build/Sanctuary-Test-beta.081.mrpack).
|
||||
SHA-256 : `7811cdc47ab4a8af2fc6ccd530775eb4a239f18894965362a1c57a5e0f12ded5`.
|
||||
@@ -0,0 +1,205 @@
|
||||
# CAPE-01 — Des capes rares aux pouvoirs durables
|
||||
|
||||
**Ticket local rédigé le 15 septembre 2026 — à arbitrer, puis à implémenter.**
|
||||
Cette livraison prépare le ticket ; les effets et l'acquisition décrits ci-dessous
|
||||
ne sont pas implémentés.
|
||||
|
||||
- Branche documentaire réservée : `codex/capes-ticket`.
|
||||
- Branche d'implémentation prévue : `codex/capes-gameplay`.
|
||||
- Aucun numéro `beta.xxx` réservé pour cette préparation documentaire.
|
||||
|
||||
## Ce que le joueur doit pouvoir faire
|
||||
|
||||
Trouver une cape Sanctuary doit être un événement : un objet très rare,
|
||||
reconnaissable et désirable, que l'on a envie de porter pour son pouvoir.
|
||||
Les capes donnent généralement un **bonus passif permanent**. Certaines peuvent
|
||||
offrir un pouvoir exceptionnel, voire volontairement « cheaté », si son impact
|
||||
reste acceptable dans la partie collective.
|
||||
|
||||
Un catalogue riche est souhaitable : il peut contenir beaucoup de modèles,
|
||||
y compris plusieurs capes très puissantes. La diversité du catalogue et le
|
||||
nombre d'exemplaires en circulation sont deux choix distincts.
|
||||
|
||||
### Intentions exprimées par le créateur
|
||||
|
||||
- Privilégier les bonus durables et l'envie d'utiliser les capes.
|
||||
- Faire des capes des objets très rares.
|
||||
- Garder ouverte la possibilité de malus ou de contreparties.
|
||||
- Accepter des pouvoirs très forts ; leur puissance seule ne les exclut pas.
|
||||
- Examiner leurs conséquences réelles sur le gameplay et les autres joueurs.
|
||||
- Envisager la rareté et des périodes de fonctionnement comme moyens
|
||||
d'équilibrage, sans rendre toutes les capes temporaires.
|
||||
|
||||
### Interprétation proposée de « permanent »
|
||||
|
||||
Le pouvoir reste disponible **tant que la cape est équipée dans sa case dédiée**,
|
||||
sans renouveler une potion ou appuyer régulièrement sur une touche. Posséder
|
||||
la cape dans un coffre ou l'inventaire n'accorde rien. Le retrait arrête son
|
||||
effet ; découvrir plusieurs capes ne donne pas plusieurs bonus permanents au
|
||||
personnage. Cette interprétation reste à confirmer avant le code.
|
||||
|
||||
Les exceptions temporaires sont annoncées cape par cape. Proposition : la cape
|
||||
reste un objet de collection après sa période active ; c'est son pouvoir qui
|
||||
s'endort. Une cape consommable ou détruite à l'expiration serait un autre choix,
|
||||
à expliciter, pas une conséquence implicite du mot « temporaire ».
|
||||
|
||||
## État réel du socle
|
||||
|
||||
La [beta.018](companions-cosmetics-beta018.md) a livré la case cape, les gestes
|
||||
d'équipement, la sauvegarde et le rendu partagé. Le code consulté contient une
|
||||
seule cape, `sanctuary:zero_cape`, disponible en créatif ou par `/give`.
|
||||
**Cape Zéro est actuellement visuelle : aucun bonus de gameplay n'est appliqué
|
||||
par son service.** Son apparence est provisoire. Le filtre d'équipement et le
|
||||
rendu reconnaissent explicitement cet objet ; un catalogue demande leur extension.
|
||||
|
||||
Les [lootboxes de capes](vision.md#panneaux-et-lootboxes) appartiennent à la vision.
|
||||
Elles ne constituent pas une acquisition en survie déjà livrée. Les familiers,
|
||||
la progression, le portage, les bateaux et le temps réel existent et devront
|
||||
être pris en compte lors des essais des effets retenus.
|
||||
|
||||
## Périmètre proposé pour un premier lot jouable
|
||||
|
||||
Livrer **trois capes aux usages distincts**, leur description FR/EN, leur effet
|
||||
serveur et une première voie d'obtention rare effectivement jouable. Le choix
|
||||
des trois capes ci-dessous est une proposition de prototype, pas un catalogue
|
||||
approuvé. Les autres modèles pourront suivre par petits lots.
|
||||
|
||||
| Piste FR / EN | Pouvoir envisagé | Point d'équilibrage à éprouver |
|
||||
| --- | --- | --- |
|
||||
| **Cape de la Brise / Breeze Cape** | Bonus permanent de vitesse de déplacement au sol. | Utilité quotidienne ; cumul avec Sprint, potions, familiers et ralentissement du portage. Un bonus simple peut rester sans malus. |
|
||||
| **Cape du Brasier / Ember Cape** | Forte augmentation des dégâts de mêlée ; réduction de la vie maximale comme contrepartie possible. | Gain offensif réellement sensible ; risque assumé et lisible. Vérifier si le malus influe sur les combats ou s'annule facilement par une combinaison. |
|
||||
| **Cape de l'Éclipse / Eclipse Cape** | Vol libre pendant une courte fenêtre récurrente, pouvoir volontairement exceptionnel. | Accès entre îles, exploration, transport et sortie de fenêtre en plein vol. Durée, fréquence et éventuelles restrictions à décider après essai. |
|
||||
|
||||
Pour chaque cape sélectionnée, renseigner avant implémentation : nom FR/EN,
|
||||
identifiant stable, visuel et provenance, effet chiffré, conditions, éventuel
|
||||
malus, cumuls, acquisition, fréquence d'obtention et règle temporelle complète.
|
||||
Le devenir de Cape Zéro reste une décision distincte : ne pas attribuer
|
||||
automatiquement un nouveau pouvoir aux exemplaires existants.
|
||||
|
||||
Ce lot réutilise la case existante. Il ne nécessite ni nouveau monde, ni nouvelle
|
||||
génération, ni économie complète, ni système général de quêtes ou de lootboxes.
|
||||
La source de récompense doit être choisie parmi les mécanismes effectivement
|
||||
disponibles au démarrage ; si elle exige un chantier autonome, la référencer
|
||||
comme dépendance. Un prototype accessible uniquement par `/give` valide les
|
||||
pouvoirs, mais ne clôt pas le résultat « trouver une cape rare en survie ».
|
||||
|
||||
## Équilibrage : mesurer ce que la cape change
|
||||
|
||||
**La rareté ne suffit pas à prouver l'équilibre.** Une cape obtenue une seule fois
|
||||
peut servir quotidiennement, être prêtée à tout un groupe ou aider son détenteur
|
||||
à en obtenir d'autres. Une faible probabilité répétable peut finir par produire
|
||||
beaucoup d'exemplaires. À l'inverse, une cape très forte dans un contexte précis
|
||||
peut créer un moment mémorable sans dominer toute la progression.
|
||||
|
||||
L'objectif proposé est que plusieurs capes aient des usages désirables, tout en
|
||||
gardant un parcours intéressant sans cape. Les exceptions qui court-circuitent
|
||||
une étape doivent être identifiées et assumées dans leur fiche.
|
||||
|
||||
| Axe | Essai à réaliser et décision à en tirer |
|
||||
| --- | --- |
|
||||
| **Exploration et vide** | Comparer un trajet entre îles sans cape, avec cape et avec moyens de transport existants. Identifier les risques supprimés, les accès anticipés et l'utilité restante des infrastructures. |
|
||||
| **Combat PvE et PvP** | Mesurer dégâts, survie et possibilité de réponse à équipement comparable, puis en combinaison forte. Décider explicitement du traitement PvP ; ne pas le désactiver par défaut dans la conception. |
|
||||
| **Progression et production** | Relever temps gagné, ressources et XP obtenues. Vérifier si une cape rend superflus une compétence, une potion, un familier ou une étape collective. |
|
||||
| **Cumuls et coopération** | Éprouver cape + familier + équipement + potions, portage et prêt entre joueurs. Une seule case cape ne limite pas les autres sources de bonus. |
|
||||
| **Rareté dans le temps** | Estimer les exemplaires et détenteurs après une semaine et un mois, pour un joueur occasionnel, un joueur intensif et un groupe qui mutualise les récompenses. |
|
||||
| **Plaisir et choix** | Observer si les joueurs veulent réellement porter chaque cape, changent selon l'activité ou choisissent toujours la même. Un malus qui conduit à tout laisser au coffre rate l'intention. |
|
||||
|
||||
Ajuster en priorité le contexte d'utilité, les cumuls, l'acquisition ou la période
|
||||
active lorsqu'ils permettent de conserver un pouvoir spectaculaire. Réduire
|
||||
la puissance ou ajouter un malus reste possible, sans imposer une pénalité à
|
||||
chaque cape. Une cape maudite à malus seul reste une piste à arbitrer.
|
||||
|
||||
### Rareté et circulation
|
||||
|
||||
- Fixer la source, les joueurs éligibles, la fréquence des tentatives, le taux
|
||||
ou quota éventuel et la possibilité de renouveler la récompense.
|
||||
- Distinguer rareté d'un modèle et rareté de l'ensemble : beaucoup de modèles
|
||||
très rares peuvent rendre l'obtention d'une cape quelconque fréquente.
|
||||
- Examiner les prêts, échanges, doublons, récompenses rejouées et New Game+.
|
||||
Liaison au joueur et exemplaire unique au serveur sont des options, pas des
|
||||
règles acquises. Les nouveaux arrivants doivent être inclus dans l'essai.
|
||||
- Documenter les hypothèses de calcul et confronter la rareté attendue à des
|
||||
essais. Un taux de butin bas, seul, n'est pas un critère d'acceptation suffisant.
|
||||
|
||||
### Périodes d'activité des capes exceptionnelles
|
||||
|
||||
Choisir, pour chaque cape concernée, **un modèle temporel explicite** : fenêtre
|
||||
commune récurrente, durée depuis l'obtention, ou budget de temps d'utilisation.
|
||||
Une période d'obtention limitée et une période d'effet limitée sont distinctes.
|
||||
|
||||
Le contrat précise l'horloge utilisée, début, fin, fréquence, temps hors ligne,
|
||||
arrêts serveur et effet des changements de mode Vanilla/Real Time. Une fenêtre
|
||||
liée à une heure réelle doit aussi être essayée du point de vue des joueurs
|
||||
qui ne peuvent pas se connecter à cette heure.
|
||||
|
||||
Le serveur fait autorité. Retirer, rééquiper, prêter, mourir, se reconnecter ou
|
||||
redémarrer ne doit pas réinitialiser involontairement une durée ou une recharge.
|
||||
L'interface indique l'état actif/dormant, le temps restant et la prochaine
|
||||
occasion lorsqu'elle est prévisible. Prévoir l'avertissement et la transition
|
||||
de fin : pour le vol, définir une sortie praticable, sans mort surprise ni
|
||||
prolongation illimitée par rééquipement.
|
||||
|
||||
## Contrat technique à écrire avant le code
|
||||
|
||||
- Une seule cape active par joueur ; effets et conditions calculés côté serveur.
|
||||
Une préférence visuelle ne peut pas accorder ou prolonger un pouvoir.
|
||||
- Appliquer et retirer uniquement la contribution de la cape. Préserver un
|
||||
effet identique venant d'une potion ou d'un familier ; préciser addition,
|
||||
multiplication, priorité ou plafond pour chaque cumul pertinent.
|
||||
- Traiter changement de cape, mort, tombe, `keepInventory`, changement de
|
||||
dimension, reconnexion et New Game+ avec les règles d'inventaire existantes.
|
||||
Définir aussi le retrait d'un bonus de vie ou d'un malus de vie maximale,
|
||||
sans soin gratuit par alternance de capes.
|
||||
- Conserver `sanctuary:zero_cape` et les emplacements existants. Tout ajout de
|
||||
données persistantes, notamment temporelles, exige un contrat de migration
|
||||
explicite et des essais sur des copies de sauvegardes de développement.
|
||||
- Décrire en FR/EN bonus, contrepartie, conditions et durée avant équipement.
|
||||
Vérifier le rendu porté et les élytres sur la version Minecraft exacte du lot.
|
||||
|
||||
## Critères d'acceptation de la future livraison
|
||||
|
||||
- [ ] Les trois fiches sont complètes ; valeurs, obtention, cumuls et traitement
|
||||
temporel sont fixés, avec les conséquences fortes assumées par la conception.
|
||||
- [ ] Un joueur peut obtenir une cape par la voie de survie retenue, l'équiper,
|
||||
comprendre son pouvoir et constater son effet réel. Une récompense unique
|
||||
ne peut pas être réclamée plusieurs fois par reconnexion.
|
||||
- [ ] Le bonus permanent reste actif au-delà de la durée d'une potion ordinaire
|
||||
tant que la cape est portée. Stockage et retrait ne laissent aucun bonus indu.
|
||||
- [ ] Deux joueurs voient un équipement cohérent ; changement rapide de cape,
|
||||
effet concurrent et prêt ne produisent ni cumul résiduel ni duplication.
|
||||
- [ ] Les limites de période fonctionnent avant, pendant et après la fenêtre,
|
||||
y compris après arrêt/reprise et transfert ; la sortie d'un pouvoir dangereux
|
||||
respecte la transition annoncée.
|
||||
- [ ] Mort/tombe, `keepInventory`, dimension, reconnexion, redémarrage et
|
||||
New Game+ conservent les objets et durées selon le contrat de migration.
|
||||
- [ ] Un compte rendu compare sans cape, chaque cape seule et les combinaisons
|
||||
les plus fortes, en début et en fin de progression, en solo et à 2–4 joueurs.
|
||||
Il relève gains, abus possibles, circulation attendue et ajustements retenus.
|
||||
- [ ] Aucun pouvoir n'est déclaré équilibré sur la seule base de sa rareté ou
|
||||
d'un build réussi ; les limites de l'essai sont documentées.
|
||||
- [ ] `./gradlew check build` passe avec les tests utiles aux effets retenus ;
|
||||
`./gradlew assemblePack` vérifie la distribution. Versions et note de livraison
|
||||
suivent [le compteur bêta](versioning.md). Parcours client FR/EN vérifié.
|
||||
|
||||
## Décisions encore ouvertes
|
||||
|
||||
1. Confirmer « permanent tant que porté » et le rôle des capes à malus seul.
|
||||
2. Choisir les trois premières capes, leurs valeurs et le devenir de Cape Zéro.
|
||||
3. Choisir la première acquisition jouable et la rareté visée, puis décider
|
||||
des échanges et des éventuels quotas.
|
||||
4. Choisir la règle temporelle des exceptions, leurs cumuls, leur traitement
|
||||
PvP et les étapes de progression qu'elles peuvent volontairement dépasser.
|
||||
|
||||
## Références vérifiées pour cette préparation
|
||||
|
||||
- [Vision : progression](vision.md#inventaire-prestige-et-déblocages) et
|
||||
[récompenses](vision.md#panneaux-et-lootboxes).
|
||||
- [Service actuel des accessoires](../mods/sanctuary/src/main/java/fr/koka/sanctuary/cosmetics/AccessoryService.java),
|
||||
[filtre et stockage](../mods/sanctuary/src/main/java/fr/koka/sanctuary/inventory/AccessoryContainer.java)
|
||||
et [rendu](../mods/sanctuary/src/main/java/fr/koka/sanctuary/mixin/client/AccessoryAvatarRendererMixin.java).
|
||||
- [Catalogue des familiers beta.032](spawn-eggs-v2-catalogue-beta032.md), à
|
||||
confronter au code courant lors des essais de cumul.
|
||||
|
||||
Validation de ce ticket : lecture du socle, vérification des références locales
|
||||
et relecture du diff documentaire. Aucun essai de gameplay ni build exécuté
|
||||
pour cette rédaction ; les critères ci-dessus concernent la future implémentation.
|
||||
@@ -0,0 +1,49 @@
|
||||
# beta.077 — tourbillon de nuages au-dessus du vide
|
||||
|
||||
Branche `codex/cloud-vortex-beta077`. Minecraft 26.3-pre-2, textures beta.070.
|
||||
|
||||
La dernière précision du créateur fixe la couche à **Y = 0**, et non 64.
|
||||
Les nuages supérieurs restent présents. Un tourbillon continu tourne autour
|
||||
du centre de l’île de Sanctuary ; son diamètre vaut deux fois celui de l’île
|
||||
(1 448 blocs / environ 91 chunks pour l’île habituelle de 724 blocs).
|
||||
Une révolution dure 20 minutes de simulation. Le style garde les cellules de
|
||||
12 blocs, l’épaisseur de 4 blocs et l’éclairage des nuages Minecraft.
|
||||
|
||||
Le serveur transmet uniquement le centre et le diamètre déjà définis par le
|
||||
générateur. Aucun chunk, bloc, sauvegarde ou génération n’est modifié. Les
|
||||
mondes classiques/plats et les autres dimensions ne reçoivent pas de couche.
|
||||
Les réglages de nuages désactivés/rapides/détaillés sont respectés.
|
||||
|
||||
La géométrie est calculée une fois puis conservée sur le GPU. La rotation et
|
||||
la couleur passent par les uniforms natifs, sans remaillage à chaque mouvement
|
||||
de caméra. Les passes normales et de transparence Fabulous réutilisent les
|
||||
pipelines de nuages du jeu. Les buffers sont libérés à la déconnexion.
|
||||
|
||||
Cette livraison inclut les [correctifs de menus beta.076](menu-navigation-beta076.md)
|
||||
et le retrait du lien web de la [bibliothèque beta.075](plans-library-beta075.md).
|
||||
|
||||
## Vérifications
|
||||
|
||||
Parcours client natif réussi en 1 min 8 s : formes connectées pour les îles de
|
||||
512, 724 et 1 024 blocs ; rendu rapide/détaillé/Fabulous (passages OIT réellement
|
||||
exécutés), rotation, vues au-dessus/dessous/dans la couche, désactivation et
|
||||
extension finie. Une seule construction de géométrie pendant les mouvements
|
||||
et changements de qualité. 5 888 cellules pour l’île habituelle.
|
||||
Captures : `build/cloud077-evidence/`.
|
||||
`check build assemblePack assembleTestPack` réussit en 3 min 22 s (124 tâches),
|
||||
avec le serveur dédié exclu conformément au refus de son EULA.
|
||||
Les 1 693 classes et les sources du JAR correspondent au build ; seuls les
|
||||
menus et le nouveau rendu changent depuis beta.075. Les textures, données de
|
||||
jeu et le resource pack restent identiques. Les onze libellés sont présents
|
||||
en FR/EN. Les deux packs sont vérifiés et 155 archives précédentes restent
|
||||
identiques. Reçu : `build/cloud077-artifact.json`.
|
||||
Pas de déploiement dans une installation personnelle ni de serveur dédié.
|
||||
Les shaders externes qui remplacent entièrement le rendu des nuages restent
|
||||
à vérifier séparément ; aucune compatibilité non testée n’est promise.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.077.mrpack](../build/Sanctuary-beta.077.mrpack), 9608669 octets.
|
||||
SHA-256 : `1c3839f086e9545c920e4ebfc13f99a25d0684fa6f2dc8e1b2a842a8e7044045`.
|
||||
- [Sanctuary-Test-beta.077.mrpack](../build/Sanctuary-Test-beta.077.mrpack), 9627602 octets.
|
||||
SHA-256 : `1b0c302b9d4d5f59d5e954adbecde4acbacd9409c8cd6a743ccbe116826d7c0a`.
|
||||
@@ -0,0 +1,36 @@
|
||||
# beta.078 — Combats / Battles
|
||||
|
||||
Branche `codex/battle-menu-beta078`. Minecraft 26.3-pre-2 ; textures beta.070.
|
||||
|
||||
Le bouton et le titre « Duels et arènes » deviennent **Combats** en français
|
||||
et **Battles** en anglais. Le lien depuis les duels de familiers utilise
|
||||
également ce libellé. Les annonces d’inscription indiquent le menu pause,
|
||||
et les résultats renvoient au nouveau nom pour récupérer les gains.
|
||||
|
||||
Le [plan des menus](menu-architecture.md) conserve cette appellation. Le reste
|
||||
de cette réorganisation reste une proposition ; l’économie est différée.
|
||||
Aucune règle de combat, sauvegarde ou transaction n’est modifiée.
|
||||
|
||||
## Vérification
|
||||
|
||||
`check build assemblePack assembleTestPack` réussi en 2 min 33 s, avec le
|
||||
serveur dédié exclu conformément au refus de son EULA. Après la précision
|
||||
du créateur sur le pluriel, les ressources et packs sont reconstruits en
|
||||
8 s ; vérification finale des quatre traductions par langue et de leurs
|
||||
paramètres de formatage.
|
||||
|
||||
Les 1 693 classes du JAR sont identiques à beta.077. Les textures, données
|
||||
de jeu et le resource pack restent inchangés. Les deux archives embarquent
|
||||
le JAR vérifié ; les archives beta.077 sont conservées à l’identique.
|
||||
Reçu : `build/battle078-artifact.json`. Journaux : `build/battle078-check.log`
|
||||
et `build/battle078-assemble.log`.
|
||||
|
||||
Pas de nouveau parcours client graphique pour ce changement de libellés.
|
||||
Aucun déploiement dans une installation personnelle.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.078.mrpack](../build/Sanctuary-beta.078.mrpack).
|
||||
SHA-256 : `9adfa5b5b8d49ed10943121ac2a2561d880886925a5f76db5ba98f0377d8d7e3`.
|
||||
- [Sanctuary-Test-beta.078.mrpack](../build/Sanctuary-Test-beta.078.mrpack).
|
||||
SHA-256 : `92bc1d59723546c31a6e7476dd9f53225c7957e5180091dfeaeade69ff265a86`.
|
||||
@@ -0,0 +1,98 @@
|
||||
# beta.074 — autonomie et ordres des familiers
|
||||
|
||||
Branche `codex/familiar-autonomy-beta074`. Implémentation et parcours client natif vérifiés.
|
||||
|
||||
## Comportements
|
||||
|
||||
| Personnalité | Décision autonome |
|
||||
| --- | --- |
|
||||
| Agressif | Engage les monstres qu’il voit à 12 blocs du joueur, accompagne ses attaques et riposte. |
|
||||
| Protecteur | Garde 6 blocs autour du joueur, intercepte en priorité les monstres qui le ciblent, défend le joueur et lui-même. Abandonne la poursuite au-delà de 10 blocs du point gardé. |
|
||||
| Passif | N’engage pas de combat spontanément ; défend le joueur attaqué et riposte s’il est frappé. |
|
||||
| Pacifiste | Évite le combat et s’écarte d’un agresseur. Attend un ordre d’attaque ou de garde. |
|
||||
|
||||
La vue est celle du familier : son propriétaire n’a pas besoin de voir le
|
||||
monstre ou de le viser. Les animaux paisibles, les monstres neutres non engagés,
|
||||
les alliés et les autres joueurs ne sont pas attaqués par la détection de
|
||||
proximité. La riposte PvP et les ordres conservent les permissions du monde,
|
||||
les factions et les règles des duels/arènes.
|
||||
|
||||
Un ordre d’attaque prime sur la personnalité et les autres menaces. « Protéger »
|
||||
ordonne explicitement de garder un allié visé, soi-même par défaut, ou le point
|
||||
visé en maintenant Maj. Même un pacifiste peut exécuter cette garde demandée.
|
||||
Pendant une poursuite spontanée, le protecteur peut changer de cible pour
|
||||
intercepter une menace qui commence à viser son joueur ou l’allié gardé.
|
||||
Une cible morte laisse place à une nouvelle décision, au plus tard lors du
|
||||
prochain balayage. Le protecteur revient près de son point de garde.
|
||||
Les espèces de soutien disposent du coup de défense lorsqu’elles s’engagent ;
|
||||
leurs signatures, leurs dégâts existants et leurs coûts en fournitures restent inchangés.
|
||||
|
||||
## Commandes
|
||||
|
||||
H bref : attaquer l’ennemi visé, ou revenir au suivi s’il n’y a pas de cible.
|
||||
H maintenu environ 0,4 seconde : ouvrir le menu d’ordres. La touche reste
|
||||
configurable ; F échange les mains, G déclenche la technique. Relâcher après
|
||||
l’ouverture du menu ne lance pas d’attaque. Les messages brefs confirment
|
||||
l’ordre. « Suivre » suspend les réactions spontanées pendant cinq secondes.
|
||||
|
||||
## Exécution et conservation
|
||||
|
||||
Une recherche d’entités chargées par seconde, décalée entre les familiers.
|
||||
Aucun chargement de chunk ; chemins demandés au maximum toutes les dix ticks.
|
||||
Une cible autonome perdue de vue cinq secondes, ou sans progression six
|
||||
secondes, est écartée temporairement pendant dix secondes. Les commandes
|
||||
explicites peuvent la désigner de nouveau. Les montures, familiers portés,
|
||||
œufs rappelés et mode travail n’entament pas de recherche autonome.
|
||||
|
||||
Le tirage de personnalité, les UUID, les 88 profils, la santé, l’XP et les
|
||||
souvenirs sont conservés. Aucun format de sauvegarde, terrain ni journal de
|
||||
mise ne change. Les règles de combat des arènes restent prioritaires.
|
||||
Textures beta.070, Minecraft 26.3-pre-2 et dépendances identiques.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Le parcours `Autonomy074ClientChecks` réussit en **1 min 44 s** avec un
|
||||
client et son serveur intégré, dans un nouveau monde plat de développement :
|
||||
|
||||
- Les quatre personnalités : recherche à 12/6 blocs, attaque du propriétaire,
|
||||
dégâts réellement reçus par le joueur et déplacement jusqu’à la cible.
|
||||
- Protecteur villageois : interruption d’une poursuite pour une menace visant
|
||||
le joueur, dégâts sans bouclier, cible suivante et retour dans la zone.
|
||||
- Abeille neutre paisible puis agressive, garde explicitement demandée à un
|
||||
pacifiste et priorité d’une cible ordonnée.
|
||||
- Vue propre au familier, obstacle opaque, cible enfermée, permissions,
|
||||
mode travail, suspension puis reprise après Suivre.
|
||||
- Événements clavier natifs : H bref/maintenu, reconfiguration sur Y,
|
||||
absence d’attaque au relâchement du menu, F natif ; fiches FR/EN.
|
||||
|
||||
La régression `Familiar071ClientChecks` réussit en **1 min 50 s** :
|
||||
352 000 identités sur les 88 profils, réactions, dégâts, araignées montées,
|
||||
Strider sur lave et les deux Nautilus aux tailles 2 500 et 6 000 ‰.
|
||||
La fermeture/réouverture du monde conserve l’UUID et le caractère.
|
||||
|
||||
Journaux : `build/autonomy074-client.log`, `build/autonomy074-mounts.log`.
|
||||
Captures de la fiche actuelle et des montures : `build/autonomy074-evidence/`.
|
||||
`Arena073ClientChecks` et la régression `Duel054Checks` passent en
|
||||
**1 min 10 s** : arènes de familiers/joueurs/mixtes, 25 inscrits simulés,
|
||||
consentement PvP, K.-O., morts réelles, mises, remboursements et récupération
|
||||
après interruption. Journal : `build/autonomy074-arenas.log`.
|
||||
`check build assemblePack assembleTestPack` réussit en **3 min 6 s**
|
||||
(124 tâches). Les deux exports packwiz sont vérifiés : **1 689 classes**
|
||||
comparées au JAR, sources testées identiques, huit libellés FR/EN mis à jour,
|
||||
ressources et textures beta.070 intactes. Seules les quatre classes sources
|
||||
prévues changent par rapport à beta.073. Les neuf archives précédentes
|
||||
beta.070 à beta.073 restent strictement identiques.
|
||||
Reçu : `build/autonomy074-artifact.json`.
|
||||
|
||||
Ces essais couvrent l’IA commune ; ils ne constituent pas un nouveau playtest
|
||||
des 88 techniques ni un test à plusieurs clients distants. Le serveur dédié
|
||||
reste exclu (`-x :sanctuary:runGameTest`) conformément au refus d’accepter
|
||||
son EULA ; les essais natifs utilisent le serveur intégré.
|
||||
Aucun monde personnel ni déploiement Prism.
|
||||
|
||||
## Archives locales
|
||||
|
||||
- [Sanctuary-beta.074.mrpack](../build/Sanctuary-beta.074.mrpack), 9595113 octets.
|
||||
SHA-256 : `cc73e93c2ae17d6b52b6c8dd53639771645c5e5becd848e2c76765e32c919c5d`.
|
||||
- [Sanctuary-Test-beta.074.mrpack](../build/Sanctuary-Test-beta.074.mrpack), 9614048 octets.
|
||||
SHA-256 : `0851e10350788b76efa96ec1a50db951a74200213399e2a4216f8d5b1b8fafcb`.
|
||||
@@ -0,0 +1,80 @@
|
||||
# beta.067 — touche du familier et dragon volant
|
||||
|
||||
Branche `codex/familiar-controls-beta067`.
|
||||
|
||||
## Contrat
|
||||
|
||||
La touche des ordres du familier passe de H à F. La touche G de technique
|
||||
reste indépendante. Le réglage H hérité est déplacé une seule fois vers F
|
||||
au démarrage ; les autres touches personnalisées restent conservées. Un
|
||||
marqueur local `config/sanctuary-familiar-key-v1.txt` permet ensuite de choisir
|
||||
à nouveau H sans être remappé au démarrage suivant. L'action reste configurable.
|
||||
|
||||
Pendant le jeu Sanctuary, ouvrir les ordres avec F ne déclenche plus l'échange
|
||||
des objets des deux mains. Le raccourci natif garde son comportement dans les
|
||||
inventaires et hors Sanctuary ; réassigner les ordres libère également F.
|
||||
|
||||
Le modèle natif du dragon utilise un axe avant opposé aux modèles vivants
|
||||
ordinaires. Son historique de vol reçoit cette correction d'orientation ;
|
||||
la direction physique du familier et des attaques reste inchangée.
|
||||
|
||||
Le petit dragon porté utilise le planeur existant : descente bornée à
|
||||
0,12 bloc par tick, distance de chute accumulée effacée. Le grand dragon porté
|
||||
(taille existante > 1 200 et < 2 500 millièmes) permet une montée maintenue avec
|
||||
la touche de saut, bornée à 0,18 bloc par tick. Relâcher reprend la descente
|
||||
planée. Le seuil colossal de 2 500 reste une monture sur laquelle le joueur
|
||||
s'assoit ; il ne peut pas être porté sur la tête. Seul le dragon reçoit la
|
||||
montée lorsqu'il est porté ; les autres petits animaux volants gardent leur
|
||||
plané et les montures colossales leur pilotage existant.
|
||||
|
||||
La physique du joueur reste native avec collisions. Le serveur n'exempte du
|
||||
contrôle d'immobilité aérienne que la montée réellement soutenue par un grand
|
||||
dragon porté et la touche de saut reçue. Retrait du familier, immersion,
|
||||
déconnexion et perte du portage interrompent l'assistance. Les règles
|
||||
existantes de collision du passager s'appliquent au dragon sur la tête.
|
||||
|
||||
Aucun changement du format des œufs, des sauvegardes ou de la génération.
|
||||
Les indications de montée dans l'infobulle utilisent la touche de saut
|
||||
configurée, avec libellés FR/EN.
|
||||
|
||||
## Vérification
|
||||
|
||||
`Familiar067ClientChecks` réussit en 55 secondes sur un monde plat de
|
||||
développement avec serveur intégré :
|
||||
|
||||
- F ouvre réellement les ordres sans changer les objets des deux mains ; H
|
||||
ne les ouvre plus. Réassigner sur K fonctionne et libère l'échange natif F.
|
||||
- La position de la tête dans le modèle de dragon soumis au rendu est devant
|
||||
le corps pour quatre directions cardinales, pas derrière.
|
||||
- Dragons de tailles 350 et 650 : Maj + clic droit natif, passager synchronisé,
|
||||
descente bornée côté client, distance de chute effacée des deux côtés ;
|
||||
Espace ne permet pas de monter avec ces petits.
|
||||
- Taille 1 500 : montée de plus de huit blocs en maintenant Espace pendant
|
||||
cent ticks, connexion maintenue, reprise du plané au relâchement, collision
|
||||
au plafond sans traversée du joueur.
|
||||
- Taille 3 500 : le joueur monte sur le dragon, puis décolle avec Espace.
|
||||
|
||||
Le plané des petits existait déjà : le parcours le confirme sur le dragon.
|
||||
Le nouveau comportement de montée concerne la catégorie « grand » portée.
|
||||
La transparence de proximité existante reste conservée.
|
||||
|
||||
Journaux : `build/familiar067-client.log` et `build/familiar067-check.log`.
|
||||
L'attente initiale de tous les chunks du rayon échouait dans le parcours ;
|
||||
le test attend désormais la partie jouable et utilise sa zone de test locale.
|
||||
`./gradlew check build assemblePack assembleTestPack` réussit en 2 min 12 s
|
||||
avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true`. Le parcours natif est lancé séparément avec
|
||||
`-PsanctuaryFamiliar067ClientTests=true -PsanctuaryClientNoVsync=true`.
|
||||
|
||||
Les deux MRpacks contiennent les 1 646 classes compilées et leurs ressources
|
||||
vérifiées. Les différences avec beta.066 se limitent aux cinq classes du
|
||||
correctif, au mixin enregistré, à l'indication FR/EN et aux versions des mods.
|
||||
JEI, les textures, les données de génération et les archives beta.066 restent
|
||||
identiques. Reçu : `build/familiar067-artifact.json`.
|
||||
|
||||
[Pack normal](../build/Sanctuary-beta.067.mrpack) ·
|
||||
[Monde plat rapide](../build/Sanctuary-Test-beta.067.mrpack).
|
||||
|
||||
Validation en client natif avec serveur intégré, sans serveur dédié ni essai
|
||||
à plusieurs clients distants. Aucun canal publié, instance personnelle ou
|
||||
monde existant modifié.
|
||||
@@ -0,0 +1,55 @@
|
||||
# beta.069 — retour des ordres du familier sur H
|
||||
|
||||
Branche `codex/familiar-orders-h-beta069`.
|
||||
|
||||
Les ordres du familier reviennent sur **H**. **F** conserve l’échange natif des
|
||||
objets entre les mains ; **G** reste la technique du familier. Les touches
|
||||
restent configurables dans les options et les libellés FR/EN existants suivent
|
||||
le raccourci assigné.
|
||||
|
||||
Le remplacement introduit en beta.067/.068 est annulé au premier démarrage :
|
||||
une ancienne affectation F des ordres devient H. Les autres touches
|
||||
personnalisées sont conservées. Le nouveau marqueur local
|
||||
`config/sanctuary-familiar-key-v2.txt` rend cette opération unique, même si le
|
||||
marqueur v1 existe déjà. Les modifications manuelles ultérieures ne sont pas
|
||||
réécrites. Le filtrage qui consommait les actions du raccourci d’échange des
|
||||
mains est supprimé. Aucun changement du serveur ou des sauvegardes.
|
||||
|
||||
## Vérifications natives
|
||||
|
||||
Le parcours `Familiar067ClientChecks`, actualisé pour le retour sur H, réussit
|
||||
en **1 min 7 s** : H ouvre les ordres sans échanger les mains ; F échange un
|
||||
diamant et un lingot d’or dans les deux sens sans ouvrir de menu ; G conserve
|
||||
son affectation par défaut ; une personnalisation des ordres sur K fonctionne.
|
||||
Le reste de ce parcours existant (orientation, plané et vol du dragon) passe
|
||||
également. Le test utilise un monde plat de développement et un serveur intégré.
|
||||
|
||||
Après le parcours, les options enregistrées sont bien H/F/G et le marqueur v2
|
||||
contient beta.069 (`build/familiar069-controls.json`). Le lanceur réinitialise
|
||||
la configuration de test ; ce parcours ne prétend donc pas valider la mise à
|
||||
jour complète d’une ancienne installation. La conversion conditionnelle F→H
|
||||
et le garde par marqueur ont été vérifiés dans le code ; la configuration
|
||||
personnelle de Prism n’a pas été modifiée.
|
||||
|
||||
Journal : `build/familiar069-client.log`. Le sélecteur de ce parcours reste
|
||||
`-PsanctuaryFamiliar067ClientTests=true`, avec `-PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true`.
|
||||
|
||||
## Livraison locale
|
||||
|
||||
`check build assemblePack assembleTestPack` réussi en **2 min 13 s**, 122 tâches,
|
||||
avec exclusion du serveur
|
||||
dédié (`-x :sanctuary:runGameTest`) et les profils client/test rapide.
|
||||
Voir `build/familiar069-check.log`. Aucun serveur dédié ni acceptation d’EULA.
|
||||
|
||||
Les 1 647 classes du mod correspondent à la compilation. Seule la classe
|
||||
`FamiliarClient` change par rapport à beta.068 ; textures, traductions,
|
||||
chargement, dragon et JEI restent identiques. Les archives beta.068 gardent
|
||||
leurs empreintes. Reçu : `build/familiar069-artifact.json`.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.069.mrpack), 5726225 octets.
|
||||
SHA-256 : `1c923452ff4d5d186309390fac3306b8e05162143c852619b7519741002aa165`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.069.mrpack), 5745158 octets.
|
||||
SHA-256 : `bed499fa29f4247a9e321207df503b3147b8b4fc8c8541d817cdfe2a2db9a945`.
|
||||
|
||||
Aucune instance personnelle ni canal public modifié.
|
||||
@@ -0,0 +1,169 @@
|
||||
# beta.071 — personnalité et engagement des familiers
|
||||
|
||||
Branche `codex/familiar-personality-beta071`.
|
||||
|
||||
## Comportement
|
||||
|
||||
Chaque œuf individualisé possède une personnalité de combat, visible dans
|
||||
son infobulle et sa fiche de familier. Les ordres restent sur H, la technique
|
||||
sur G et l’échange des mains sur F.
|
||||
|
||||
| Personnalité | Réaction spontanée | Poursuite | Cadence d’initiative |
|
||||
| --- | --- | --- | --- |
|
||||
| Agressif | Engage les monstres proches, accompagne les attaques et riposte | ×1,55 | délai ×0,90 |
|
||||
| Protecteur | Accompagne les attaques et défend le joueur, l’allié protégé et lui-même | ×1,45 | délai habituel |
|
||||
| Passif | Riposte seulement lorsqu’il est frappé | ×1,35 | délai ×1,05 |
|
||||
| Pacifiste | S’éloigne du danger, sans attaque automatique | ×1,35 sur ordre | délai habituel |
|
||||
|
||||
**Tous obéissent à un ordre explicite d’attaque**, y compris le pacifiste.
|
||||
Une autre menace ne remplace pas une cible désignée tant qu’elle reste valide.
|
||||
Un Enderman ou un Piglin zombifié non engagé est laissé tranquille ; les
|
||||
familiers et les joueurs ne déclenchent pas cette recherche de proximité. Le PvP conserve ses règles et les
|
||||
duels leur consentement. Suivre suspend les réactions automatiques cinq
|
||||
secondes ; Rappeler ou le mode travail interrompent l’engagement spontané.
|
||||
|
||||
Les vitesses sont des multiplicateurs de navigation : la poursuite utilisait
|
||||
auparavant ×1,15. L’approche gagne donc environ 17 à 35 % selon le caractère,
|
||||
sans changer la vitesse de promenade, celle des montures ni les dégâts.
|
||||
Les attaques à distance gardent leur distance utile. Les feintes au contact
|
||||
cessent suffisamment tôt pour entrer réellement à portée. Les préparations
|
||||
d’attaque restent lisibles : leurs durées ne sont pas raccourcies.
|
||||
|
||||
Les espèces de soutien conservent leurs techniques signature. Un villageois
|
||||
agressif, ou un soutien explicitement envoyé attaquer, dispose d’un coup au
|
||||
contact (2 dégâts de base, préparation 0,25 s, intervalle 2 s), sans exiger un
|
||||
bouclier dans l’inventaire du joueur. Les techniques offensives natives des
|
||||
espèces restent utilisées.
|
||||
|
||||
## Individus et tendances
|
||||
|
||||
Le tirage utilise l’UUID déjà enregistré et l’identifiant d’espèce. Sa fonction
|
||||
et son sel sont figés dans `FamiliarPersonality`. Il ne dépend ni du nom, ni
|
||||
de la taille, ni de l’XP, ni du propriétaire ou de la reconnexion. Les anciens
|
||||
œufs identifiés reçoivent donc un caractère stable sans conversion de fichier.
|
||||
Un œuf sans identité le découvre à sa première individualisation habituelle.
|
||||
|
||||
| Tendance d’espèce | Agressif | Protecteur | Passif | Pacifiste |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Vindicateur et espèces farouches listées dans le code | 70 % | 20 % | 7 % | 3 % |
|
||||
| Villageois et espèces paisibles listées dans le code | 5 % | 15 % | 25 % | 55 % |
|
||||
| Autres espèces et futurs profils sans règle spécifique | 25 % | 40 % | 25 % | 10 % |
|
||||
|
||||
Toutes gardent des exceptions. Le tempérament historique hors combat
|
||||
(curieux, calme, joueur), les souvenirs, les identifiants, les 88 profils et
|
||||
les schémas de sauvegarde restent intacts. Changer ces seuils ultérieurement
|
||||
changerait le caractère d’œufs existants : cela demanderait un contrat de
|
||||
migration, pas une simple retouche d’équilibrage.
|
||||
|
||||
## Araignées
|
||||
|
||||
L’araignée et l’araignée venimeuse utilisent la navigation d’escalade native.
|
||||
En monture colossale, avancer contre une paroi les fait grimper à environ
|
||||
quatre blocs par seconde. Relâcher ou s’écarter permet de redescendre. La
|
||||
vérification porte sur le corps de l’araignée : un plafond touché par le joueur
|
||||
ne déclenche pas une ascension. Les collisions du corps et de la tête du
|
||||
cavalier restent actives. Un espace vide n’autorise aucune montée.
|
||||
|
||||
L’éligibilité à la monte reste celle des familiers colossaux ; les petits
|
||||
familiers se portent selon les règles existantes.
|
||||
|
||||
## Effets des montures natives
|
||||
|
||||
Audit du code de Minecraft **26.3-pre-2** : `AbstractHorse` et ses variantes,
|
||||
`Camel`/`CamelHusk`, `Pig`, `Strider`, `HappyGhast` et
|
||||
`AbstractNautilus`/`Nautilus`/`ZombieNautilus`. Les sources de comparaison
|
||||
sont extraites du JAR utilisé par le build dans `build/native071-source/`.
|
||||
|
||||
| Espèces natives pouvant recevoir un cavalier | Effet transmis au cavalier | Trait de déplacement |
|
||||
| --- | --- | --- |
|
||||
| Cheval, âne, mule, cheval squelette, cheval zombie | Aucun effet d’état natif | Déplacement et saut terrestres |
|
||||
| Lama, lama de marchand | Aucun | Montables, mais pas pilotables en vanilla |
|
||||
| Dromadaire, dromadaire momifié | Aucun | Déplacement terrestre ; dash natif distinct d’un effet d’état |
|
||||
| Cochon | Aucun | Direction à la carotte sur bâton en vanilla |
|
||||
| Strider | Aucun bonus de résistance au feu au joueur | Appui à la surface de la lave |
|
||||
| Ghast joyeux | Aucun | Vol |
|
||||
| Nautilus, Nautilus zombie | **Souffle du Nautilus** | Nage et dash natifs |
|
||||
|
||||
Le Souffle du Nautilus est ajouté au moment de monter et entretenu tant que
|
||||
le joueur reste sur son Nautilus colossal. Il utilise l’effet Minecraft
|
||||
original : durée de 60 ticks, renouvellement toutes les 40 ticks, niveau zéro.
|
||||
L’air restant est figé sous l’eau, sans être rempli comme avec une potion.
|
||||
Après la descente, l’effet expire naturellement sous trois secondes ; il
|
||||
n’est pas supprimé brutalement au risque d’effacer une autre source.
|
||||
|
||||
Il fonctionne pour les deux espèces, sur toute la plage colossale existante
|
||||
(2 500 à 6 000 ‰, y compris les plus grands « titans »), sans achat de
|
||||
technique ou condition de personnalité. Porter simplement l’œuf ou le petit
|
||||
familier sur sa tête ne donne pas cet effet de **cavalier**.
|
||||
|
||||
Le Strider retrouve le support de collision de lave et la remontée natifs,
|
||||
avec une infobulle dédiée. Il maintient son cavalier au-dessus de la surface ;
|
||||
ce n’est pas une immunité personnelle à la lave après avoir sauté du Strider.
|
||||
|
||||
Les autres espèces n’appliquent pas de potion native à leur cavalier : aucune
|
||||
n’a été inventée. Les commandes Sanctuary de ces montures restent communes,
|
||||
comme demandé lors de leur introduction. Cet audit des traits ne porte pas
|
||||
les selles, harnais, coffres d’équidés, sièges supplémentaires, charges de saut
|
||||
ou commandes de dash propres aux interfaces natives. Les pouvoirs familiers
|
||||
existants restent disponibles selon leurs règles.
|
||||
|
||||
## Coût et validation
|
||||
|
||||
La recherche agressive est locale, dans les entités déjà chargées à huit
|
||||
blocs du propriétaire, une fois par seconde, décalée entre familiers. Aucun
|
||||
chargement de chunk. La navigation reste limitée à une demande de chemin
|
||||
par dix ticks. Les décisions et les dégâts font autorité côté serveur.
|
||||
|
||||
Le parcours `Familiar071ClientChecks` réussit en **2 min 23 s** dans un
|
||||
nouveau monde plat de développement, avec le client et son serveur intégré :
|
||||
|
||||
- 352 000 UUID répartis entre les 88 espèces ; quatre caractères possibles,
|
||||
tendances villageois/vindicateur, stabilité après changement d’XP et de souvenirs.
|
||||
- Quatre personnalités de loups : réactions aux événements, ordre explicite,
|
||||
navigation jusqu’à la cible et dégâts réels. Verrouillage de combat maintenu
|
||||
même pour un familier qui refuse l’engagement spontané.
|
||||
- Villageois agressif : initiative spontanée et dégâts sans bouclier ; la cible
|
||||
manuelle garde sa priorité. Fiche FR/EN et nom du familier inspectés.
|
||||
- Araignée et araignée venimeuse colossales : touches natives, ascension du mur,
|
||||
collision du cavalier avec le plafond et absence de montée dans l’espace vide.
|
||||
- Strider colossal : déplacement avec les touches natives à la surface d’un
|
||||
bassin de lave, cavalier hors de la lave et sans potion de résistance au feu.
|
||||
- Nautilus et Nautilus zombie : tailles 2 500 et 6 000 ‰, cavalier effectivement
|
||||
immergé, air figé à 40 pendant 90 ticks, renouvellement de l’effet, expiration
|
||||
et reprise de la consommation après la descente. Équiper l’œuf seul ne le donne pas.
|
||||
- Fermeture puis réouverture réelle du monde : même UUID et même personnalité.
|
||||
|
||||
Les captures sont dans `build/familiar071-evidence/`, le journal dans
|
||||
`build/familiar071-client.log`. La matrice de personnalité couvre les 88
|
||||
profils ; elle ne constitue pas un nouveau playtest de toutes leurs techniques.
|
||||
Pas de validation à deux clients distants ou sur serveur dédié dans cette passe.
|
||||
|
||||
La construction de la distribution est effectuée dans
|
||||
`build/familiar071-workspace/` : les sources de la release beta.070, puis les
|
||||
changements ciblés de la 71. Cette copie évite de compiler les fichiers de
|
||||
statues de la beta.072 ajoutés simultanément dans le dossier partagé.
|
||||
`build/familiar071-source-snapshot.json` fixe les empreintes de cette copie.
|
||||
Les sources courantes du familier conservent les mêmes changements.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en **5 min 50 s**,
|
||||
124 tâches (108 exécutées, 16 à jour), dans cette copie isolée. Le serveur
|
||||
dédié `:sanctuary:runGameTest` reste exclu conformément au refus d’accepter
|
||||
son EULA ; le parcours natif utilise uniquement le serveur intégré du client.
|
||||
|
||||
Les deux exports MRpack sont vérifiés : version exacte, dépendances figées,
|
||||
JAR comparé aux **1 651 classes compilées** et aux ressources traitées,
|
||||
égalité normal/Test sauf module de test, absence de classes de test dans le
|
||||
mod livré. Seuls les neuf fichiers Java prévus et douze libellés par langue
|
||||
changent par rapport à beta.070 ; les schémas, le catalogue, JEI, le code de
|
||||
Demeure et les 150 fichiers du resource pack restent identiques. Le manifeste
|
||||
de Demeure suit seulement le nouveau numéro du pack.
|
||||
|
||||
Reçu et empreintes : `build/familiar071-artifact.json`.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.071.mrpack), 9 462 323 octets.
|
||||
SHA-256 : `1ab36663fe24313597c5328170a3eb2ca2e33bfdfc4c6fbc85c1f5c03102628c`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.071.mrpack), 9 481 258 octets.
|
||||
SHA-256 : `06309f4cd382053fb42d80c3f131152932e07523ace799c50d1d899026029a92`.
|
||||
|
||||
Le resource pack demeure beta.070, actif par défaut et désactivable. Aucun
|
||||
monde personnel, aucune instance Prism et aucun canal public ne sont modifiés.
|
||||
@@ -0,0 +1,67 @@
|
||||
# beta.079 — ordres et défense des familiers en solo
|
||||
|
||||
Branche `codex/familiar-solo-beta079`, Minecraft 26.3-pre-2, textures beta.070.
|
||||
|
||||
Signalement : les familiers paraissent passifs en solo ; H ouvre le menu,
|
||||
mais les ordres ne semblent pas exécutés. Espèces citées : slime, loup, poule.
|
||||
|
||||
## Causes reproduites
|
||||
|
||||
L’ouverture du menu H envoie `refresh`. Cette lecture consommait la même
|
||||
limite de fréquence que les ordres : un clic immédiatement après l’ouverture
|
||||
était rejeté sans message. La mise à jour possède désormais sa propre limite,
|
||||
sans affaiblir celle des actions. Le test natif échouait sur Rappeler avant
|
||||
cette correction et réussit ce passage après séparation des requêtes.
|
||||
|
||||
Suivre suspendait pendant cinq secondes toutes les réactions automatiques,
|
||||
y compris la défense du joueur attaqué. Le délai ne concerne désormais que
|
||||
les initiatives spontanées. Une personnalité qui défend son propriétaire
|
||||
ou riposte peut réagir immédiatement aux dégâts. Le pacifiste conserve son
|
||||
comportement ; l’ordre explicite de protection reste prioritaire.
|
||||
|
||||
Les ordres du menu confirment leur réception : suivi, attaque, protection
|
||||
ou rappel. Une attaque sans familier disponible, sur une cible refusée ou
|
||||
avec un familier porté/monté donne une explication au lieu d’une confirmation
|
||||
d’attaque inexécutable. FR/EN disponibles. H bref et H maintenu sont conservés.
|
||||
|
||||
Le mode utilitaire continue de suspendre les attaques autonomes. La santé,
|
||||
les UUID, les personnalités, les capacités et les sauvegardes sont conservés.
|
||||
Les nouveaux compteurs de requêtes sont temporaires côté serveur ; aucune
|
||||
migration ni modification d’un monde personnel.
|
||||
|
||||
## Vérification
|
||||
|
||||
Deux reproductions natives avant correction : rejet de Rappeler juste après
|
||||
l’ouverture de H ; absence de défense d’un loup passif juste après Suivre.
|
||||
Le scénario utilise un nouveau monde plat solo de développement, sans
|
||||
commandes, sans droits opérateur et sans achat du Lien actif.
|
||||
|
||||
`Solo079ClientChecks` réussit en **1 min 53 s** : rappel immédiatement après
|
||||
l’ouverture de H, retour au suivi, garde du joueur, attaques ordonnées et
|
||||
défense immédiate après Suivre pour le loup, le slime et la poule. Les tests
|
||||
attendent le déplacement et la frappe, contrôlent la baisse de santé et
|
||||
identifient le familier comme auteur du dégât, pour exclure le soleil ou les
|
||||
autres dégâts environnementaux. Les confirmations sont reçues côté client.
|
||||
|
||||
`Autonomy074ClientChecks` réussit en **1 min 58 s** : quatre personnalités,
|
||||
garde, vue et obstacles, cibles neutres, priorité des ordres, permissions,
|
||||
mode utilitaire, délai avant les poursuites spontanées, H bref/maintenu,
|
||||
touche reconfigurée et échange des mains avec F. Fiches FR/EN vérifiées.
|
||||
|
||||
Journaux : `build/solo079-client-final.log`, `build/solo079-regression.log`.
|
||||
Captures : `build/solo079-evidence/`.
|
||||
`check build assemblePack assembleTestPack` réussit en **2 min 21 s**,
|
||||
124 tâches, avec `-x :sanctuary:runGameTest` conformément au refus du serveur
|
||||
dédié. Les 1 693 classes du JAR correspondent au build ; seules
|
||||
`FamiliarBattle` et son état temporaire changent par rapport à beta.078.
|
||||
Deux nouveaux libellés par langue, ressources et textures inchangées.
|
||||
Sources vérifiées, même JAR embarqué dans les deux packs ; archives beta.078
|
||||
conservées à l’identique. Reçu : `build/solo079-artifact.json`.
|
||||
Aucun déploiement personnel ; les essais utilisent le serveur intégré.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.079.mrpack](../build/Sanctuary-beta.079.mrpack).
|
||||
SHA-256 : `7df042d720e2511310387183efcc432cafec4786623e530e5552fd2ba36ca7db`.
|
||||
- [Sanctuary-Test-beta.079.mrpack](../build/Sanctuary-Test-beta.079.mrpack).
|
||||
SHA-256 : `0ca193b2918c7d650503c2ce2fa97d2b3c626fee5ddd99df0cf51ea05a2bb82e`.
|
||||
@@ -0,0 +1,81 @@
|
||||
# beta.062 — soleil et chapeaux des familiers
|
||||
|
||||
Branche `codex/familiar-sunlight-beta062`.
|
||||
|
||||
Le familier reprend la sensibilité solaire du type natif de son œuf : tag
|
||||
`minecraft:burn_in_daylight`, avec respect de l'immunité native au feu. La
|
||||
vérification utilise le moteur Minecraft 26.3-pre-2 : lumière, ciel dégagé,
|
||||
eau/pluie/neige poudreuse et attribut environnemental `MONSTERS_BURN`.
|
||||
Les bébés familiers concernés brûlent aussi. Les autres espèces conservent
|
||||
leur comportement actuel.
|
||||
|
||||
Tout objet équipé dans l'emplacement de tête Sanctuary protège des nouvelles
|
||||
inflammations solaires, sur un mob ordinaire comme sur un familier. Maj + clic
|
||||
droit avec un objet l'équipe ; Maj + clic droit à main vide le récupère.
|
||||
L'armure de tête native conserve sa protection et son usure habituelles quand
|
||||
aucun chapeau Sanctuary n'est équipé. Un chapeau ne rend pas résistant au feu :
|
||||
une flamme déjà allumée termine sa durée native, ou s'éteint dans l'eau.
|
||||
|
||||
Les familiers sensibles perdent leur santé de combat en brûlant, jusqu'au K.-O.
|
||||
habituel, sans détruire l'œuf. Leur feu reste dangereux pendant un duel ; les
|
||||
attaques extérieures au duel restent exclues. Les flammes suivent la taille
|
||||
visible du compagnon. Une indication FR/EN sur les œufs concernés explique le
|
||||
besoin d'un chapeau, sans achat préalable d'une aptitude.
|
||||
|
||||
Aucun identifiant ni format de sauvegarde ne change. Le chapeau utilise
|
||||
l'équipement existant : il est rendu au sol quand le familier disparaît et
|
||||
n'est pas stocké dans son œuf. Aucun monde existant ni canal n'est modifié.
|
||||
|
||||
## Vérifications
|
||||
|
||||
`Sunlight062ClientChecks` passe dans le client natif 26.3-pre-2, sur un monde
|
||||
plat de développement neuf :
|
||||
|
||||
- 88 œufs exposés au moteur solaire natif : zombies, villageois zombies,
|
||||
noyés, chevaux zombies, nautiles zombies, squelettes, vagabonds, embourbés
|
||||
et phantoms brûlent ; les autres conservent leur immunité, dont le Wither
|
||||
squelette naturellement résistant au feu ;
|
||||
- mob ordinaire avec pierre, diamant, bâton et torche en chapeau, protection
|
||||
et usure du casque natif conservées, reprise du feu après retrait ;
|
||||
- vrai paquet Maj + clic droit pour équiper puis retirer un diamant de la
|
||||
tête du familier, synchronisation de l'objet sur son modèle côté client ;
|
||||
- santé persistée qui baisse sur les vrais ticks de feu, feu déjà allumé qui
|
||||
expire sous un chapeau, absence de nouvelle inflammation ;
|
||||
- toit, nuit, pluie et immersion ; l'eau éteint aussi les flammes existantes ;
|
||||
- K.-O. déclenché par un tick natif de brûlure, identité et œuf conservés ;
|
||||
- brûlure et fin normale d'un duel au K.-O., refus des coups directs d'un
|
||||
joueur extérieur et des autres dégâts environnementaux pendant le duel ;
|
||||
- flammes synchronisées aux dimensions visibles du familier bébé, capture
|
||||
inspectée dans `build/sun062-evidence/sunburn.png`, indication FR/EN.
|
||||
|
||||
Journal `build/sun062-client.log` : **55 s**, marqueurs
|
||||
`SUNLIGHT062_SPECIES_PASS` et `SUNLIGHT062_PASS`. La première tentative de
|
||||
lancement a été arrêtée au blocage OpenGL de synchronisation verticale ;
|
||||
le parcours réussi utilise `-PsanctuaryClientNoVsync=true` et le réglage VSync
|
||||
uniquement dans le dossier du client de développement.
|
||||
|
||||
L'essai de duel utilise deux entités serveur avec une connexion simulée pour
|
||||
la seconde ; aucun essai avec deux clients humains n'est revendiqué. La
|
||||
capture inspectée est celle du zombie bébé ; le rendu individuel des huit
|
||||
autres espèces sensibles n'a pas été revu visuellement.
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest
|
||||
-PsanctuaryClientTests=true -PsanctuarySunlight062ClientTests=true
|
||||
-PsanctuaryQuickTests=true` réussit : **122 tâches**, **2 min 10 s**.
|
||||
Le parcours client est exécuté séparément par `:sanctuary:runClientGameTest`
|
||||
avec les mêmes propriétés et `-PsanctuaryClientNoVsync=true`.
|
||||
Aucun EULA de serveur dédié n'a été accepté.
|
||||
|
||||
## Archives locales
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.062.mrpack), 5678508 octets.
|
||||
SHA-256 : `3eb3729023bcb1f6931198d50694ecac1fee1c660aeb0cf1edc9776aebbfe2fa`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.062.mrpack), 5697441 octets.
|
||||
SHA-256 : `f71dd47ef228d2acab99fe9b7b58e11d4f39234f926d7a313956bdd69e9cd2b6`.
|
||||
|
||||
Les **1624 classes** embarquées correspondent au build. Le reçu
|
||||
`build/sun062-artifact.json` vérifie le contenu des archives, les différences
|
||||
ciblées avec beta.061, les dépendances imbriquées et la conservation des
|
||||
archives précédentes. JEI, la génération et les autres ressources du pack
|
||||
restent identiques. Aucun canal publié, instance personnelle ni monde
|
||||
existant n'est modifié.
|
||||
@@ -0,0 +1,60 @@
|
||||
# beta.085 — textures du Fourneau
|
||||
|
||||
Les trois images originales de 48 × 48 pixels fournies par le créateur sont
|
||||
conservées, octet pour octet, dans `assets/sanctuary/textures/block/fourneau/`.
|
||||
Chaque image couvre une face entière du cube de trois blocs de côté. Les UV
|
||||
des 27 composants prélèvent chacun un tiers de l'image, à la densité native
|
||||
de 16 pixels par bloc. Façade dans l'orientation choisie à l'assemblage ;
|
||||
côtés et arrière avec `side`, dessus et dessous avec `top`.
|
||||
|
||||
## Contrat de compatibilité
|
||||
|
||||
Aucun changement au schéma 1 de `sanctuary:multiblocks`, aux identifiants des
|
||||
blocs ou aux données de leurs inventaires. Les assemblages beta.084 utilisent
|
||||
leur orientation déjà enregistrée. Un four isolé garde le modèle de son pack
|
||||
de ressources. Les nouveaux modèles ne s'appliquent qu'aux fours assemblés.
|
||||
Dissocier ou casser un composant rétablit les modèles ordinaires ; cuisson,
|
||||
combustible et objets restent dans les BlockEntities vanilla.
|
||||
|
||||
Le serveur transmet seulement l'apparence des machines dans les chunks
|
||||
suivis par le joueur : à l'envoi natif du chunk, à l'assemblage et à la
|
||||
dissociation. Aucun paquet par tick de cuisson. Le client invalide les
|
||||
sections concernées et utilise les modèles de blocs natifs via Fabric,
|
||||
avec éclairage, occultation des faces et destruction habituels. Il efface
|
||||
son cache au déchargement d'un chunk, au changement de monde et à la
|
||||
déconnexion. Les modèles sont rebâtis lors du rechargement des ressources.
|
||||
|
||||
Les modèles JSON se régénèrent avec `python3 tools/generate-fourneau-models.py`.
|
||||
Les textures originales ne sont pas générées. Le pack intégré beta.070
|
||||
reste inchangé : ces nouveaux assets appartiennent au mod beta.085.
|
||||
|
||||
## Limites visuelles
|
||||
|
||||
Aucune variante allumée n'a été fournie : l'image reste celle du créateur,
|
||||
y compris pendant la cuisson. L'état lumineux natif du Fourneau est conservé.
|
||||
Le Fût conserve son apparence de barils dans cette livraison.
|
||||
|
||||
## Vérifications et livraison
|
||||
|
||||
- `check build assemblePack assembleTestPack` : tâches réussies dans
|
||||
`build/fourneau085-check.log`. La première extension du test visuel de chauffe
|
||||
surveillait par erreur la case de diamants, qui ne cuit pas ; son attente a
|
||||
échoué après les tâches de construction. Le scénario a été corrigé pour
|
||||
observer le compartiment contenant le minerai, sans changement du code livré.
|
||||
- `Fourneau085ClientChecks` relancé avec succès : nouveau monde plat intégré,
|
||||
quatre orientations, 27 modèles répartis sur quatre chunks, état allumé,
|
||||
rechargement des ressources, rejet d'un paquet d'une autre dimension,
|
||||
déchargement réel puis retour, dissociation, casse et conservation des
|
||||
17 diamants stockés. Journal final : `build/fourneau085-client-final.log`.
|
||||
- Contrôle des trois PNG à l'octet près, des 108 modèles et de leurs UV,
|
||||
des sources embarquées, des archives et de la préservation des assets
|
||||
antérieurs. Reçu : `build/fourneau085-artifact.json`.
|
||||
- Captures natives : `build/fourneau085-screenshots/`, dont
|
||||
`0001_fourneau085-north.png` et `0006_fourneau085-lit.png`.
|
||||
|
||||
Archives locales vérifiées : `build/Sanctuary-beta.085.mrpack` et
|
||||
`build/Sanctuary-Test-beta.085.mrpack`. Les archives beta.084 restent inchangées.
|
||||
Le canal packwiz et l'instance Prism n'ont pas été déployés. Aucun monde
|
||||
personnel modifié, aucune EULA acceptée, aucun serveur dédié lancé : le test
|
||||
utilise uniquement le serveur intégré au client. Le rendu avec deux clients
|
||||
LAN distincts et avec un moteur de shaders tiers reste à éprouver séparément.
|
||||
@@ -0,0 +1,60 @@
|
||||
# beta.088 — Navigation du Fût sans recentrage de souris
|
||||
|
||||
Branche : `codex/fut-navigation-beta088`.
|
||||
|
||||
## Problème et correction ciblée
|
||||
|
||||
Changer de page ou appliquer une recherche remplaçait le menu serveur via
|
||||
`openMenu`. Minecraft envoyait d'abord une fermeture au client, puis une
|
||||
ouverture. Cette fermeture reprenait la souris pour le jeu et la recentrait,
|
||||
obligeant à revenir sur le bouton à chaque clic.
|
||||
|
||||
La transition nettoie désormais l'ancien menu côté serveur avec
|
||||
`doCloseContainer`, sans envoyer l'écran de fermeture intermédiaire. Le
|
||||
nouveau menu est ensuite ouvert normalement : la souris reste libérée et
|
||||
conserve sa position. Cela concerne la pagination et la recherche du Fût,
|
||||
ainsi que les onglets du Fourneau qui utilisent la même navigation.
|
||||
|
||||
Chaque page garde un nouvel identifiant de menu : les paquets de clics ou de
|
||||
navigation de la page précédente sont toujours rejetés. Les contrôles de
|
||||
portée, d'accès, de structure, d'objet porté au curseur et la limite de
|
||||
fréquence restent en place. La fermeture réelle du coffre reste native.
|
||||
Aucun changement de stockage, de sauvegarde, de textures ou de libellés.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Le parcours natif existant a été étendu avec un contrôle des paquets réseau
|
||||
sur un second joueur de test : sans correction, la navigation envoie un
|
||||
`ClientboundContainerClosePacket` et le test échoue. Avec la correction,
|
||||
aucune fermeture intermédiaire, et une fermeture réelle envoie toujours
|
||||
son paquet. Ce contrôle reste valable si la fenêtre de test est inactive.
|
||||
|
||||
Côté client, le test place réellement le curseur sur le bouton puis clique
|
||||
trois fois sur Suivant et deux fois sur Précédent sans le déplacer. Sa
|
||||
position est vérifiée après chaque page, après une recherche localisée en
|
||||
français et après chacun des trois onglets du Fourneau. Échap ferme le menu
|
||||
normalement côté client et côté serveur.
|
||||
|
||||
Les essais existants passent également : 729 cases, deux joueurs utilisant
|
||||
le même stock, objets au curseur, identifiants périmés, transfert rapide,
|
||||
hoppers, démontage, casse, persistance et cuisson native partagée.
|
||||
Aucun serveur dédié lancé, aucune EULA acceptée, aucun monde personnel touché.
|
||||
|
||||
Journaux : `build/fut088-before-client.log` (régression reproduite) et
|
||||
`build/fut088-client.log` (succès en 39 secondes). Le parcours reste activé
|
||||
par `-PsanctuaryMultiblocks084ClientTests=true` avec
|
||||
`-PsanctuaryClientTests=true -PsanctuaryQuickTests=true`.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en 2 min 23 s
|
||||
(124 tâches, 103 exécutées), avec le GameTest dédié explicitement exclu.
|
||||
Journal : `build/fut088-check.log`. Le reçu `build/fut088-artifact.json`
|
||||
vérifie les sources, le JAR, les archives normal/Test et la conservation de
|
||||
tous les assets beta.087. Seules `MultiblockMenu` et sa classe interne de
|
||||
transfert changent dans les classes compilées (décalage des lignes de debug
|
||||
pour cette dernière).
|
||||
|
||||
Livraison locale : `build/Sanctuary-beta.088.mrpack` et
|
||||
`build/Sanctuary-Test-beta.088.mrpack`. Les archives beta.087 restent intactes.
|
||||
Aucun déploiement dans l'instance Prism ni sur le canal publié. Un essai LAN
|
||||
avec deux clients distincts reste à réaliser ; le test d'accès partagé utilise
|
||||
un second joueur serveur dans le client de développement.
|
||||
@@ -0,0 +1,51 @@
|
||||
# beta.086 — textures du Fût
|
||||
|
||||
Le Fût assemblé reçoit les trois images originales de 48 × 48 pixels :
|
||||
côtés, dessus et dessous. Chacune couvre une face entière de trois blocs
|
||||
sur trois, avec 16 pixels par bloc et sans retouche de l'image.
|
||||
|
||||
## Contrat avant implémentation
|
||||
|
||||
Aucun changement de sauvegarde : les 27 barils et leurs 729 cases restent
|
||||
vanilla, avec le même registre d'appartenance et les mêmes données. Seul le
|
||||
modèle affiché change quand le Fût est assemblé. Les barils indépendants
|
||||
conservent le modèle du pack de ressources actif. Dissociation et casse
|
||||
rétablissent leur apparence. Les textures du Fourneau beta.085 sont conservées.
|
||||
|
||||
Le Fût ajoute un paquet client `sanctuary:fut_appearance_v1` ; le paquet
|
||||
du Fourneau reste inchangé. Les deux utilisent la même mise en cache visuelle
|
||||
par chunk et le même rendu natif. Aucun paquet supplémentaire par tick,
|
||||
aucun stockage parallèle d'objets. Le pack intégré beta.070 reste inchangé ;
|
||||
les textures du Fût appartiennent aux assets du mod beta.086.
|
||||
|
||||
## Rendu et vérifications
|
||||
|
||||
Les modèles JSON se régénèrent avec `python3 tools/generate-fut-models.py`.
|
||||
Les PNG sources sont conservés dans `assets/sanctuary/textures/block/fut/`.
|
||||
Aucune variante ouverte n'a été fournie : le Fût conserve le même dessus
|
||||
pendant l'accès à son inventaire.
|
||||
|
||||
`Fut086ClientChecks` a réussi dans un nouveau monde plat intégré : Fût et
|
||||
Fourneau voisins, modèles distincts, raccords des côtés/dessus/dessous,
|
||||
ouverture et prélèvement dans les 729 cases, rechargement des ressources,
|
||||
déchargement réel puis retour dans quatre chunks, dissociation et casse.
|
||||
Les objets conservés restent dans les mêmes barils physiques ; retirer la
|
||||
façade du Fût ne retire pas celle du Fourneau voisin.
|
||||
|
||||
Journal du client : `build/fut086-client.log`. Captures natives :
|
||||
`build/fut086-screenshots/`, notamment `0001_fut086-top-side.png` et
|
||||
`0002_fut086-bottom-side.png`. Le Fût est suspendu dans cette scène de test
|
||||
pour que le dessous puisse être inspecté.
|
||||
|
||||
`check build assemblePack assembleTestPack` a réussi en 2 min 36 s
|
||||
(124 tâches, 104 exécutées), sans serveur dédié ; journal
|
||||
`build/fut086-check.log`. Le reçu `build/fut086-artifact.json` vérifie
|
||||
l'identité des PNG, les 27 modèles, les sources embarquées et les archives,
|
||||
ainsi que la conservation de tous les assets beta.085 du Fourneau.
|
||||
|
||||
Livraison locale : `build/Sanctuary-beta.086.mrpack` et
|
||||
`build/Sanctuary-Test-beta.086.mrpack`. Les archives beta.085 restent
|
||||
immuables. Aucun déploiement sur Prism ou sur le canal publié, aucun monde
|
||||
personnel modifié, aucune EULA acceptée. Les vérifications multijoueur
|
||||
avec deux clients distincts et avec un moteur de shaders tiers restent
|
||||
à effectuer séparément.
|
||||
@@ -0,0 +1,77 @@
|
||||
# Synchronisation Git jusqu’à beta.092
|
||||
|
||||
Ticket du 16 septembre 2026, branche `codex/git-sync-beta092`.
|
||||
|
||||
Le dépôt distant était resté sur [beta.061](git-sync-beta061.md). Cette
|
||||
synchronisation enregistre les sources, ressources, outils et comptes rendus
|
||||
locaux jusqu’à la livraison **beta.092**, pour **Minecraft 26.3**. Elle inclut
|
||||
le commit déjà local du resource pack beta.070. `main` avance directement et
|
||||
le tag exact `beta.092` désigne les sources de la livraison vérifiée.
|
||||
|
||||
Le compteur reste à beta.092 : ce rattrapage n’ajoute aucun changement de jeu.
|
||||
Les documents de conception restent des intentions, selon leurs contrats.
|
||||
Les anciens tags et les posts de release existants sont conservés. Les versions
|
||||
intermédiaires ne reçoivent pas artificiellement un tag pointant sur beta.092.
|
||||
|
||||
## Sources et vérifications
|
||||
|
||||
Une copie des 2 636 fichiers sources non ignorés est figée dans un worktree
|
||||
isolé, sans modifier les fichiers de travail. Les JAR générés, archives ZIP,
|
||||
MRpack, sauvegardes et dépendances téléchargées restent ignorés ; seul le
|
||||
wrapper Gradle est versionné. Les références courantes des README sont mises
|
||||
à jour, avec ce compte rendu.
|
||||
|
||||
Les journaux et le reçu de la [livraison beta.092](multiblock-pick-beta092.md)
|
||||
confirment :
|
||||
|
||||
- `./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
réussi en **3 min 1 s**, **124 tâches**.
|
||||
- Parcours client natif `Pick092ClientChecks` réussi en **1 min 19 s**, avec
|
||||
`PICK092_PASS` : **864 états**, douze combinaisons normal/gluant et six
|
||||
directions, vrais clics molette, inventaire de survie, parties mobiles et
|
||||
Ctrl + clic sans données techniques.
|
||||
- Les empreintes des deux MRpack locaux correspondent au reçu de livraison.
|
||||
|
||||
La copie destinée à Git est reconstruite sous Java 25 avec :
|
||||
|
||||
```sh
|
||||
./gradlew assemblePack assembleTestPack \
|
||||
-x :sanctuary:check -x :demeure:check \
|
||||
-x :jei:check -x :sanctuary-test:check
|
||||
```
|
||||
|
||||
Réussite en **48 s**, **23 tâches**. Les contrôles déjà réussis sur la livraison
|
||||
ne sont pas relancés pour cette copie. La vérification des manifestes packwiz
|
||||
et des ressources graphiques passe pendant l’assemblage. Les quatre JAR
|
||||
reconstruits sont **identiques octet pour octet** à ceux de la livraison :
|
||||
|
||||
| JAR | Entrées | Classes |
|
||||
| --- | ---: | ---: |
|
||||
| Sanctuary beta.092 | 2 960 | 1 753 |
|
||||
| Demeure beta.092 | 24 | 14 |
|
||||
| Sanctuary Test beta.092 | 25 | 3 |
|
||||
| JEI 30.32.0-sanctuary.3 pour 26.3 | 1 378 | 1 101 |
|
||||
|
||||
Les 811 fichiers Java des trois modules Sanctuary, Demeure et Test correspondent
|
||||
également aux archives de sources de la livraison. Les ressources, métadonnées
|
||||
et dépendances imbriquées sont incluses dans la comparaison des JAR.
|
||||
|
||||
SHA-256 du JAR Sanctuary :
|
||||
`8eb91eb41d0236ac6d6d064e9638c99802d28a2d83b8aef5ff1291c9495bcc8c`.
|
||||
|
||||
Reçus locaux ignorés : `build/git-sync-beta092-verification.json`,
|
||||
`build/git-sync-beta092-assemble.log`, `build/pick092-artifact.json`,
|
||||
`build/pick092-check.log` et `build/pick092-client.log`.
|
||||
|
||||
## Limites et distribution
|
||||
|
||||
Les essais beta.092 utilisent un client macOS et son serveur intégré ; pas de
|
||||
session LAN à deux clients. Le serveur GameTest dédié est exclu et aucune EULA
|
||||
n’est acceptée. La dernière exécution générale consignée dans le rattrapage
|
||||
[beta.060](git-sync-beta060.md#vérifications) comptait 235 réussites sur 246,
|
||||
avec 11 échecs à trier ; elle ne constitue pas une validation de beta.092.
|
||||
Cette synchronisation ne prétend pas résoudre ces échecs ni valider Windows/Linux.
|
||||
|
||||
Les sources et leur tag sont publiés sur Git. Les archives bêta restent locales,
|
||||
le canal packwiz reste sur alpha.30.7 et aucune instance Prism, sauvegarde
|
||||
personnelle ou installation de serveur n’est modifiée.
|
||||
@@ -0,0 +1,65 @@
|
||||
# beta.066 — cosmétiques animés sans doublon
|
||||
|
||||
Branche `codex/cosmetic-render-beta066`.
|
||||
|
||||
## Contrat
|
||||
|
||||
Un coffre porté n'affiche qu'un coffre : son couvercle s'ouvre et se ferme
|
||||
sans laisser un second coffre fermé dessous. Une cloche portée conserve
|
||||
son support et une seule cloche qui oscille. Le même correctif s'applique
|
||||
aux modèles partagés avec les mobs portant un cosmétique.
|
||||
|
||||
Minecraft 26.3 distingue la géométrie du bloc posé de son modèle isolé.
|
||||
Ce dernier peut déjà inclure un coffre fermé, une cloche fixe ou un livre.
|
||||
Sanctuary dessinait ce modèle isolé puis le rendu animé de l'entité de bloc.
|
||||
Le rendu avec une entité de bloc utilise désormais la géométrie native du
|
||||
bloc posé pour ses parties fixes, avec les teintes et la lumière du bloc,
|
||||
puis l'entité de bloc pour les parties animées.
|
||||
|
||||
Les panneaux conservent leur modèle isolé : Sanctuary soumet séparément
|
||||
leur texte, pas une deuxième planche. Les bannières et les têtes conservent
|
||||
leur rendu personnalisé ; les lits et portes gardent leurs deux moitiés.
|
||||
Le feu de camp conserve sa base et les aliments synchronisés. Aucun asset
|
||||
n'est remplacé. Aucun changement serveur, d'interaction, de stockage,
|
||||
de sauvegarde ou de génération.
|
||||
|
||||
## Vérification
|
||||
|
||||
Le parcours `Cosmetic066ClientChecks` crée un monde plat de développement,
|
||||
utilise les modèles et le collecteur de rendu natifs, et reçoit les événements
|
||||
du serveur intégré. Avant correction, le test reproduit deux soumissions
|
||||
`ChestModel` pour un seul cosmétique ouvert. Après correction, les
|
||||
contrôles n'en comptent plus qu'une.
|
||||
|
||||
Le parcours client réussit en 40 secondes :
|
||||
|
||||
- coffres normal, piégé, de l'Ender et Shulker : une seule représentation,
|
||||
ouverture et fermeture issues des événements serveur ;
|
||||
- cloche : un seul modèle animé, un support fixe, oscillation puis arrêt ;
|
||||
- feu de camp : base conservée et aliment reçu du serveur visible ;
|
||||
- table d'enchantement : un seul livre sur sa base ; panneaux, bannière,
|
||||
tête de joueur, lit complet, porte complète, four et étagère conservés ;
|
||||
- douze cas de coffres/cloches sur poules, vaches et zombies adultes ou bébés.
|
||||
|
||||
Le test compte les soumissions réelles de modèles, pas seulement la présence
|
||||
d'un état d'animation. Les captures avant/après du coffre et celle de la cloche corrigée ont
|
||||
été relues dans `build/cosmetic066-evidence/`.
|
||||
|
||||
Journaux : `build/cosmetic066-before.log`, `build/cosmetic066-client.log`.
|
||||
`./gradlew check build assemblePack assembleTestPack` réussit en 2 min 22 s
|
||||
avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true`. Le parcours client dédié utilise aussi
|
||||
`-PsanctuaryCosmetic066ClientTests=true -PsanctuaryClientNoVsync=true`.
|
||||
Les tests avec serveur dédié restent exclus ; la validation des animations
|
||||
utilise le serveur intégré du client.
|
||||
|
||||
Les deux archives sont vérifiées contre les 1 645 classes et les ressources
|
||||
compilées. Seul `HeadCosmeticModels` change dans les sources principales
|
||||
par rapport à beta.065. Les textures, JEI et les archives beta.065 restent
|
||||
identiques. Le code de Demeure reste identique ; sa version suit le pack.
|
||||
Reçu : `build/cosmetic066-artifact.json` ; build : `build/cosmetic066-check.log`.
|
||||
|
||||
[Pack normal](../build/Sanctuary-beta.066.mrpack) ·
|
||||
[Monde plat rapide](../build/Sanctuary-Test-beta.066.mrpack).
|
||||
Archives locales, sans publication du canal ni déploiement personnel.
|
||||
Une session avec plusieurs clients distants n'a pas été relancée.
|
||||
@@ -0,0 +1,68 @@
|
||||
# beta.068 — animation discrète du préchargement
|
||||
|
||||
Branche `codex/loading-animation-beta068`, ticket LOAD-03.
|
||||
|
||||
## Comportement
|
||||
|
||||
Une ligne de neuf glyphes SGA, encadrée de crochets ASCII, accompagne les
|
||||
étapes réelles de préparation. Elle utilise la police d’enchantement native
|
||||
`minecraft:alt` : les lettres de Sanctuary, avec une lumière grise/blanche
|
||||
qui parcourt la ligne dans les deux sens en 3,2 secondes. Le fond uni et les
|
||||
textes Minecraft restent sobres. Aucun pourcentage fictif ni nouvelle texture.
|
||||
|
||||
L’animation dépend de l’horloge monotone lue pendant chaque rendu, pas des
|
||||
ticks : elle continue pendant les longs calculs d’une même phase. Les glyphes
|
||||
sont préparés une seule fois, sans sondage de terrain ni travail serveur.
|
||||
|
||||
La même ligne accompagne ensuite le téléchargement natif du terrain, sous la
|
||||
carte des chunks lorsqu’elle existe. La carte et la barre de progression de
|
||||
Minecraft conservent leur rendu et leur comportement. Si une interface trop
|
||||
petite ne laisse pas de place sous les chunks, l’indicateur est masqué plutôt
|
||||
que de recouvrir la progression. Les transports par portail sont hors de ce
|
||||
changement. L’introduction longue, sa musique, le flash et Hello World restent
|
||||
inchangés, comme le cache dérivé et les étapes publiées par le serveur.
|
||||
|
||||
## Vérifications natives
|
||||
|
||||
Client natif 26.3-pre-2 réussi en **41 s**. Huit captures pendant une phase
|
||||
identique, avec la méthode `tick()` de l’écran volontairement inactive. Les
|
||||
sept comparaisons de pixels successives diffèrent uniquement dans la ligne
|
||||
de glyphes ; le titre, le fond et l’étape restent identiques.
|
||||
|
||||
Inspection FR/EN dans la fenêtre native 854 × 480, réglages GUI 2/3/4 avec
|
||||
le plafonnement automatique de Minecraft à la taille disponible. La carte des
|
||||
chunks et sa barre native restent visibles ; le message générique hors
|
||||
préparation garde son rendu habituel. Ces écrans de test utilisent des états
|
||||
fixes, sans créer de monde ni simuler un pourcentage dans le code livré.
|
||||
Les caches et les cycles de démarrage n’ont pas été modifiés ni remesurés ici.
|
||||
|
||||
Preuves locales : `build/loading068-client.log`, les captures et la comparaison
|
||||
`build/loading068-evidence/animation-check.json`. Le test ne lance aucun serveur
|
||||
et ne demande aucune acceptation d’EULA.
|
||||
|
||||
```sh
|
||||
JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryLoading068ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
## Livraison locale
|
||||
|
||||
`check build assemblePack assembleTestPack` réussi en **2 min 15 s**, 122 tâches,
|
||||
avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true`. Aucun serveur dédié lancé.
|
||||
|
||||
Les **1 647 classes** de l’archive correspondent à la compilation. Seuls
|
||||
`LoadingGlyphs`, `PreloadScreenMixin` et `PreloadTerrainScreenMixin` changent
|
||||
par rapport à beta.067. Intro, Hello World, cache, logique serveur, textures,
|
||||
sons, traductions et JEI restent identiques. Les archives beta.067 gardent
|
||||
leurs empreintes. Reçu : `build/loading068-artifact.json`.
|
||||
|
||||
- [Pack normal beta.068](../build/Sanctuary-beta.068.mrpack), 5726390 octets.
|
||||
SHA-256 : `cfb55d414186e6be5f0e19770049158302d4fbf37c0fa696306acda428594a2e`.
|
||||
- [Monde plat rapide beta.068](../build/Sanctuary-Test-beta.068.mrpack), 5745324 octets.
|
||||
SHA-256 : `643913caf577ee61b23747f378e9a21f5b1a54531901791d47d8ad0a75531dff`.
|
||||
|
||||
Aucun déploiement dans Prism, aucune publication du canal et aucun monde
|
||||
personnel modifié.
|
||||
@@ -0,0 +1,138 @@
|
||||
# beta.064 — cache des plans et préchargement natif
|
||||
|
||||
Branche `codex/loading-cache-beta064`. Reprend l'audit beta.063 et conserve les
|
||||
travaux préexistants (HUD du resource pack et documentation des capes inclus).
|
||||
|
||||
## Contrat du cache dérivé
|
||||
|
||||
Le cache est facultatif et reconstructible dans `cache/sanctuary-plans-v1/`
|
||||
sous le dossier du monde. Il ne change aucun chunk, aucun journal d'expansion,
|
||||
aucune donnée d'habitant ni les paramètres du générateur. Un ancien monde sans
|
||||
cache suit exactement le calcul existant et remplit le cache ; supprimer ce
|
||||
répertoire rétablit le même calcul. Pas de migration de sauvegarde nécessaire.
|
||||
|
||||
Les clés comprennent la graine, le générateur et ses paramètres, l'option
|
||||
structures, les versions des mods et toutes les couches de ressources de
|
||||
génération (`worldgen`, `structure`, `tags`, `dimension`, `dimension_type`) et
|
||||
les modèles NBT locaux de `generated/`. Les
|
||||
plans structurels incluent aussi la liste des îles concernées. Un changement
|
||||
invalide le cache ; une entrée illisible, incomplète ou dont l'empreinte diffère
|
||||
est ignorée puis recalculée. Écriture temporaire, synchronisation et renommage
|
||||
atomique. Aucun objet Minecraft vivant, monde, chunk ou état RNG n'est sérialisé.
|
||||
Les index dérivés sont reconstruits à partir des géométries validées.
|
||||
|
||||
Le cache couvre l'hydrologie régionale (eau, terrasses, écoulements et lave),
|
||||
les traversées, salles souterraines, sanctuaire minier, ruines et patrimoine de
|
||||
la racine, ainsi que les pièces natives du village, des mines, des temples et
|
||||
des ruines asséchées. Ces dernières utilisent le NBT natif de Minecraft, dont
|
||||
la lecture doit restituer exactement la même écriture ; sinon elles sont
|
||||
recalculées. Les pièces restaurées appartiennent au nouveau serveur, sans
|
||||
réutiliser les objets du serveur précédent. Le lecteur vanilla des pièces jigsaw
|
||||
recalcule leurs limites à partir du modèle et perd les extensions réservées aux
|
||||
jonctions : le cache réapplique ces limites enregistrées, puis exige une égalité
|
||||
NBT complète. Cette correction reste locale au lecteur du cache, sans mixin de
|
||||
chargement des chunks ni modification des structures sauvegardées.
|
||||
|
||||
Les plans aériens conservent leur journal persistant existant, qui fait
|
||||
également autorité. Les anciennes générations et les villes des expansions
|
||||
conservent leurs planificateurs actuels ; la livraison cible les plans de
|
||||
l'île Sanctuary actuelle (`generation24`, terrain alpha.30.7).
|
||||
|
||||
## Préchargement
|
||||
|
||||
Texte et étapes issus du travail réel du serveur intégré, fond uni et graphisme
|
||||
Minecraft. Aucun portail du Nether dans cette préparation. L'introduction,
|
||||
Hello World, sa durée, sa musique et le flash restent inchangés. Les étapes de
|
||||
calcul n'affichent pas de pourcentage inventé ; Minecraft fournit sa progression
|
||||
réelle des chunks dès qu'elle est disponible. La préparation locale affiche
|
||||
les étapes publiées par le serveur intégré avant même l'admission réseau.
|
||||
Un client distant ne reçoit pas de faux état d'un serveur qui n'a pas encore
|
||||
ouvert sa connexion : il conserve les étapes natives du téléchargement.
|
||||
Le transport dimensionnel par portail reste un écran Minecraft distinct.
|
||||
|
||||
Les libellés FR/EN suivent le travail : vérification/lecture du cache, eau et
|
||||
lave, traversées, salles, sanctuaire minier, ruines, patrimoine, îlots aériens,
|
||||
village, mines, temples, enregistrement et point d'arrivée. Deux lignes
|
||||
centrées sur fond uni remplacent l'attente générique ; aucune texture ajoutée.
|
||||
La progression native des chunks et ses conditions de fermeture restent gérées
|
||||
par Minecraft. Aucun nouveau bouton d'annulation ne force un arrêt au milieu
|
||||
d'un calcul ou d'une écriture.
|
||||
|
||||
## Vérification reproductible
|
||||
|
||||
Client natif 26.3-pre-2, serveur intégré uniquement, monde de développement
|
||||
neuf : graine `42`, île moyenne de diamètre `724`, structures actives,
|
||||
distances de rendu et simulation de `8`. Première arrivée avec les 29,5 secondes
|
||||
d’introduction complètes. Ensuite réouverture du même monde, puis remplacement
|
||||
d’une seule entrée de cache par un contenu tronqué et nouvelle réouverture.
|
||||
|
||||
Le contrôle compare les géométries des plans, l’eau et la lave, les index par
|
||||
colonne et par chunk, les écritures de blocs et de butin des renderers et une
|
||||
grille de points de protection. La lecture des pièces natives exige une égalité
|
||||
NBT complète après restauration. Les essais de fichiers couvrent l’absence,
|
||||
le changement de clé, une copie sous une mauvaise identité, un checksum faux,
|
||||
une validation refusée et un gzip tronqué. Chaque refus retombe sur le calcul.
|
||||
|
||||
L’écran est rendu par Minecraft en FR/EN pour inspection visuelle. Les phases
|
||||
observées pendant le véritable démarrage sont enregistrées indépendamment des
|
||||
ticks du client, qui ne tournent pas pendant sa première boucle de chargement.
|
||||
Mesure locale du 15 septembre 2026, même scénario que l’audit beta.063 :
|
||||
|
||||
| Parcours | Durée jusqu’au jeu |
|
||||
|---|---:|
|
||||
| Première création, cache vide, introduction complète | 122,255 s |
|
||||
| Réouverture avec cache | 2,126 s |
|
||||
| Entrée structurelle corrompue, recalcul automatique | 39,177 s |
|
||||
| Référence beta.063, réouverture sans cache | 58,701 s |
|
||||
|
||||
Il s’agit d’une mesure sur cette machine et cette graine, pas d’une garantie de
|
||||
durée. Le cache accélère surtout les réouvertures ; un monde neuf doit toujours
|
||||
calculer ses plans et préparer ses chunks. Les mises à jour de version ou de
|
||||
ressources invalident volontairement les anciennes entrées. La première
|
||||
réouverture d’un ancien monde sans cache sert à le remplir.
|
||||
|
||||
Réouverture : **3 lectures réussies, 0 échec, 0 écriture**. Récupération :
|
||||
**3 lectures réussies, 1 échec attendu, 1 remplacement**. Comparaison identique
|
||||
des **217 053 écritures de blocs/butin** et de 93 150 points de protection,
|
||||
ainsi que des plans et des index fluides. Les 17 étapes utiles du scénario ont
|
||||
été observées ; les libellés FR/EN et les captures natives sont vérifiés.
|
||||
Preuves locales : `build/loading064-client.log`,
|
||||
`build/loading064-evidence/timings.json` et captures dans le même dossier.
|
||||
|
||||
|
||||
```sh
|
||||
JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryLoading064ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Le drapeau de test rapide facilite l’automatisation ; ce scénario réactive
|
||||
explicitement l’introduction longue avant la validation de Hello World.
|
||||
Aucun serveur dédié lancé, aucune EULA acceptée, aucun monde personnel modifié.
|
||||
|
||||
|
||||
## Livraison locale
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack` réussi en **2 min 21 s**,
|
||||
**122 tâches**, avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryQuickTests=true`. Le parcours natif plat/classique, avec Sanctuary
|
||||
activé/désactivé puis réouverture, passe ses **8 ouvertures** en 53 s
|
||||
(`build/gameplay064-client.log`). Les tests dédiés exclus restent remplacés ici
|
||||
par les essais du serveur intégré, conformément au refus d’accepter leur EULA.
|
||||
|
||||
Archives comparées à beta.063 : **1 645 classes conformes à la compilation**,
|
||||
ressources FR/EN, mixins, métadonnées, dépendances exactes et absence de tests
|
||||
dans le mod. Les classes de Hello World, de l’introduction, les sons, les
|
||||
textures, les données de génération et JEI sont inchangés. Les variantes
|
||||
normal/Test diffèrent uniquement par le module de test rapide et leur nom.
|
||||
Les anciens MRpacks beta.063 conservent leurs empreintes originales.
|
||||
|
||||
- [Pack normal beta.064](../build/Sanctuary-beta.064.mrpack), 5720330 octets.
|
||||
SHA-256 : `c05b78e2caf27d52cb318979ee66e19e5bca9c90673f8868ae50f85f0e2ff2c0`.
|
||||
- [Monde plat rapide beta.064](../build/Sanctuary-Test-beta.064.mrpack), 5739264 octets.
|
||||
SHA-256 : `962800291875ab5bebda1abaedc798e7cf110ba0ef13ac168a0b85b3b2c19d24`.
|
||||
|
||||
Reçu : `build/loading064-artifact.json`. Aucun canal publié ni instance Prism
|
||||
modifié. Les optimisations de sondages partagés et de parallélisation de la
|
||||
première création proposées dans l’audit restent des tickets ultérieurs.
|
||||
@@ -0,0 +1,231 @@
|
||||
# beta.063 — audit du chargement et règle de jeu Sanctuary
|
||||
|
||||
> Suite livrée dans [beta.064](loading-cache-beta064.md) : cache des plans et
|
||||
> étapes réelles sur fond uni, sans le portail de la proposition ci-dessous.
|
||||
> L’audit et les mesures beta.063 restent conservés ici.
|
||||
|
||||
Branche `codex/loading-audit-gameplay-beta063`, après beta.062 conservée.
|
||||
|
||||
## Contrat
|
||||
|
||||
L'audit mesure séparément le démarrage du client, la création du terrain,
|
||||
Hello World, l'introduction et l'arrivée. Il compare une île neuve, sa
|
||||
réouverture, un monde plat et un monde Minecraft classique, sans utiliser
|
||||
de sauvegarde personnelle. L'habillage du préchargement est une proposition
|
||||
à examiner, pas une optimisation de terrain déjà livrée.
|
||||
|
||||
La règle native `sanctuary:use_sanctuary`, « Utiliser Sanctuary », permet
|
||||
de choisir les règles Sanctuary à la création d'un monde, indépendamment
|
||||
de son générateur. Elle est activée par défaut dans le pack ; la désactiver
|
||||
avant la création conserve les capacités ordinaires du joueur. Activée sur
|
||||
un monde plat ou classique, elle apporte Hello World, la progression,
|
||||
l'inventaire, les familiers, les factions et les systèmes qui en dépendent,
|
||||
ainsi que les modes temporel et météorologique Sanctuary.
|
||||
|
||||
Cette règle ne change jamais le générateur, le spawn natif, les chunks ou les
|
||||
structures du monde choisi. Les fonctions propres aux îles et aux expansions
|
||||
restent réservées à ce terrain. Les ressources et ajouts autonomes du mod
|
||||
restent chargés, y compris quand cette règle est désactivée.
|
||||
|
||||
Le choix est fixé pour la partie : les commandes et options d'une partie
|
||||
déjà ouverte ne peuvent pas le basculer. Le serveur conserve le choix natif
|
||||
dans `level.dat` ; les données existantes d'habitant continuent d'identifier
|
||||
une partie Sanctuary lors des réouvertures. Pas de nouveau format propriétaire.
|
||||
Les parties Sanctuary et le module plat de test antérieurs conservent leur
|
||||
admission historique ; la protection existante des anciennes parties sans
|
||||
progression reste appliquée. Aucun Overworld classique déjà joué n'est
|
||||
converti automatiquement. Une conversion reste hors de cette livraison,
|
||||
conformément à la précision de l'utilisateur.
|
||||
|
||||
## Mesures du 15 septembre 2026
|
||||
|
||||
Client natif Minecraft **26.3-pre-2**, Fabric **0.19.5**, API
|
||||
**0.160.0+26.3**, Java 25 ; Mac Apple M1, huit processeurs logiques,
|
||||
tas JVM 2 Gio. Une exécution par scénario dans le même client, dans cet
|
||||
ordre, avec enregistrement JFR `profile`. Graine **42**, île Moyen **724**,
|
||||
structures actives, distances de rendu et de simulation **8**. Les autres
|
||||
applications du bureau restent ouvertes. Ce sont des observations locales,
|
||||
pas une moyenne représentative ni une preuve de gain entre versions.
|
||||
|
||||
Le compteur commence à la demande de création/ouverture. « Jouable » signifie
|
||||
joueur présent, écran de jeu actif et fondu d'arrivée terminé. Hello World est
|
||||
validé automatiquement ; le temps passé à choisir son personnage est exclu.
|
||||
L'introduction complète reste active, même sur les terrains Minecraft.
|
||||
|
||||
| Scénario | Hello World prêt | Fin de la séquence d'introduction | Jouable |
|
||||
| --- | ---: | ---: | ---: |
|
||||
| Nouvelle île Sanctuary | 74,292 s | 103,889 s | **122,101 s** |
|
||||
| Réouverture de cette île | Déjà accompli | Non rejouée | **58,701 s** |
|
||||
| Nouveau monde plat + Sanctuary | 0,929 s | 30,489 s | **33,246 s** |
|
||||
| Nouveau monde classique + Sanctuary | 3,809 s | 33,458 s | **37,632 s** |
|
||||
|
||||
Le premier lancement du processus client jusqu'au début du parcours au menu
|
||||
prend environ **15 s**, en plus de ces durées. Il utilise les ressources déjà
|
||||
présentes sur cette machine : ce n'est pas une installation ou un cache disque
|
||||
à froid. Le profilage commence aux scénarios monde ; ce démarrage client est
|
||||
chronométré, mais pas attribué fonction par fonction.
|
||||
|
||||
## Ce qui se passe réellement
|
||||
|
||||
1. Le client charge les classes, ressources, textures et sons. L'enregistrement
|
||||
des services Sanctuary n'est pas encore la planification complète des îles.
|
||||
2. Après « Créer », le serveur intégré construit les niveaux. Dans
|
||||
`ExpansionRuntime.register`, l'événement `ServerLevelEvents.LOAD` prépare les
|
||||
plans du générateur : eau, traversées, réseaux souterrains, sanctuaire minier,
|
||||
patrimoine, village et expéditions. Cette étape bloque l'accès à Hello World.
|
||||
3. Le serveur choisit le spawn et prépare les chunks d'arrivée. La configuration
|
||||
réseau ouvre Hello World puis l'introduction ; une partie de la préparation
|
||||
du monde continue pendant ces **29,5 s** de cinéma.
|
||||
4. La séquence se termine, mais le monde peut ne pas être prêt. L'écran blanc
|
||||
couvre alors l'attente, puis le fondu rend le jeu visible. Sur l'île mesurée,
|
||||
environ **18,2 s** séparent la fin de l'intro de l'état jouable.
|
||||
|
||||
La première planification de l'Overworld occupe environ **58,8 s** entre
|
||||
`SERVER_STARTING` et la fin de son événement `LOAD`. À la réouverture, elle
|
||||
occupe encore **56,8 s**. La majeure partie de ces plans est recalculée à chaque
|
||||
nouvelle instance du générateur ; le journal aérien existant ne met pas tous
|
||||
les autres plans en cache.
|
||||
|
||||
Le `Time elapsed` natif est trompeur pour cet audit : il annonce **434 ms** à
|
||||
la réouverture alors que l'entrée prend **58,7 s**. Ce compteur démarre après
|
||||
les calculs lourds. Il ne doit pas servir seul de mesure du chargement complet.
|
||||
|
||||
## Où part le CPU
|
||||
|
||||
Les journaux de cette réouverture attribuent **23,913 s** aux traversées,
|
||||
**14,590 s** au patrimoine, **7,758 s** au sanctuaire minier et **2,999 s** au
|
||||
village. L'hydrologie annonce **13,052 s**, mais elle est appelée pendant la
|
||||
préparation des traversées : **ne pas additionner ces deux durées**.
|
||||
|
||||
Dans les échantillons JFR des méthodes Java en exécution à la réouverture :
|
||||
|
||||
| Méthode | Part des échantillons |
|
||||
| --- | ---: |
|
||||
| `SmearedPerlinNoise.addToVolume` | 37,81 % |
|
||||
| `NoiseStack.Perlin.get` | 22,80 % |
|
||||
| `GradientNoise.permute` | 8,51 % |
|
||||
|
||||
Ces trois fonctions de bruit totalisent **69,12 %** des échantillons. Ce n'est
|
||||
ni une part exacte du temps mural ni un gain récupérable annoncé. Les pauses
|
||||
GC totalisent **838 ms** sur le profil de réouverture, contre **1,71 s** pour
|
||||
la création de l'île. La pression mémoire existe, mais elle n'explique pas
|
||||
l'essentiel de cette attente ; augmenter seulement la RAM ne cible pas le
|
||||
coût dominant identifié.
|
||||
|
||||
Les profils incluent quelques secondes de jeu et la fermeture du monde.
|
||||
Une première tentative avec `waitForChunksDownload()` a attendu la complétion
|
||||
du rendu au-delà de l'arrivée jouable ; elle est conservée à part et exclue
|
||||
des résultats ci-dessus. Les assertions finales utilisent la présence du joueur,
|
||||
l'écran natif et la fin du fondu, pas ce critère plus strict du banc de tests.
|
||||
|
||||
Sources : `ExpansionRuntime.java:35`, `SanctuaryChunkGenerator.java:93` et `:291`,
|
||||
`ProgressionService.java:194`, `IntroScreen.java:51` et `:170`,
|
||||
`IntroSpawnFlash.java:20`. Les appels répétés à `prepareTransit` sont gardés :
|
||||
certains sont protégés et certains prennent en compte les liens du patrimoine.
|
||||
L'audit n'en déduit pas qu'ils peuvent simplement être supprimés.
|
||||
|
||||
## Habillage proposé, après retour utilisateur
|
||||
|
||||
**Conserver toute l'introduction**, sa durée, sa musique au dévoilement du
|
||||
portail et son flash. L'habillage proposé concerne uniquement l'attente qui
|
||||
précède Hello World et la réouverture d'une partie.
|
||||
|
||||
Écran sobre proche de Minecraft : fond sombre uni, portail natif au centre,
|
||||
texte Minecraft discret et bouton Annuler natif. Aucun grand logo ajouté,
|
||||
aucune carte décorative, aucun encadrement ni panneau de diagnostic permanent.
|
||||
Les textures du portail, de l'obsidienne, du bouton et la police bitmap de la
|
||||
proposition proviennent des ressources locales de Minecraft 26.3-pre-2.
|
||||
|
||||
Le texte décrit l'étape réelle : ressources, calcul du terrain, préparation
|
||||
des alentours. Une barre et un compte de chunks peuvent apparaître uniquement
|
||||
lorsque leur total est connu ; les calculs de plans restent sans faux pourcentage.
|
||||
Le compteur `86 / 225` de la maquette est un exemple d'état, pas une mesure.
|
||||
Annuler demande un arrêt propre au serveur, sans quitter au milieu d'une
|
||||
écriture. Son comportement réel devra être intégré et testé avec l'écran.
|
||||
|
||||
La proposition interactive a été simplifiée après rejet de la première
|
||||
direction. **Elle n'est pas intégrée au rendu du jeu dans beta.063.**
|
||||
|
||||
## Prochains tickets proposés
|
||||
|
||||
| Priorité | Résultat vérifiable | Garde-fous / validation |
|
||||
| --- | --- | --- |
|
||||
| 1 — Cache des plans | Réouvrir une île en relisant ses plans dérivés validés | Clé graine, révision de génération, paramètres et configurations ; écriture atomique ; corruption ou cache absent → recalcul ; comparaison exacte des plans et chunks, sans régénérer de monde utilisateur. Contrat de cache à formaliser avant développement. |
|
||||
| 2 — Préchargement natif | Afficher l'écran épuré dès le début de la création et à la réouverture | Phases instrumentées, fermeture propre, texte FR/EN, annulation et erreur visibles ; intro intacte ; mesures du coût de l'écran. |
|
||||
| 3 — Réutiliser les sondages | Éviter les colonnes de terrain recalculées entre plusieurs planificateurs | Cache borné, mêmes entrées et mêmes valeurs, empreintes bit à bit sur plusieurs graines ; reprendre la méthode de `docs/initial-loading.md`. |
|
||||
| 4 — Travail en parallèle | Réduire le chemin critique restant après les caches | Seulement sur données immuables ; aucun accès au niveau Minecraft depuis des threads arbitraires ; gains mesurés et déterminisme vérifié. |
|
||||
|
||||
Aucun gain de ces futurs tickets n'est compté comme livré. La génération et
|
||||
ses paramètres sont inchangés dans beta.063. La proposition respecte le choix
|
||||
de conserver l'intro ; l'attente blanche mesurée reste un constat, pas une
|
||||
modification autorisée de cette séquence.
|
||||
|
||||
## Utiliser la règle de jeu
|
||||
|
||||
À la création d'un nouveau monde, choisir le terrain **classique** ou
|
||||
**plat**, puis laisser **Utiliser Sanctuary : Oui** dans les règles de jeu,
|
||||
catégorie Joueur. Hello World et les règles Sanctuary s'appliquent au terrain
|
||||
natif. Les capacités ordinaires sont conservées avec **Non**. Ce choix ne
|
||||
nécessite pas une installation du module de test rapide.
|
||||
|
||||
`/gamerule sanctuary:use_sanctuary` permet de consulter le réglage. Une tentative
|
||||
de changement en jeu est refusée avec une explication FR/EN ; les autres règles
|
||||
restent modifiables. La capture du choix se fait au chargement de l'Overworld :
|
||||
dans cette version, `getGlobalGameRules()` n'est pas disponible avant sa création.
|
||||
|
||||
## Vérifications
|
||||
|
||||
- Audit client natif : île neuve, même île réouverte, plat et classique neufs,
|
||||
intro complète ; `LOADING063_AUDIT_PASS`.
|
||||
- Parcours fonctionnel client et serveur intégré : plat/classique × activé/
|
||||
désactivé, chacun créé puis réouvert, soit **8 ouvertures** ;
|
||||
`GAMEPLAY063_PASS`. Vérifie Hello World uniquement si activé, sa non-répétition,
|
||||
le familier initial conservé, les 3/10 cœurs et 1/4 rangées selon le mode,
|
||||
l'absence de session d'expansion sur terrain natif, le temps et la météo.
|
||||
- Vérifie le refus des mutations en jeu des règles globales et du niveau,
|
||||
le refus explicite de la commande et la modification d'une autre gamerule.
|
||||
Libellé et description natifs testés en français et en anglais.
|
||||
- La non-conversion des anciens mondes classiques repose sur la garde
|
||||
d'admission examinée dans le code ; aucun monde personnel n'est ouvert.
|
||||
|
||||
Commandes reproductibles (Java 25) :
|
||||
|
||||
```sh
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryLoading063ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryGameplay063ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Preuves locales ignorées : `build/loading063-audit.log`,
|
||||
`build/loading063-evidence/timings.tsv` (extrait des événements du journal),
|
||||
les deux profils JFR d'île et leurs vues CPU/GC dans ce même dossier,
|
||||
`build/gameplay063-client.log`. Les JFR plat/classique du dossier temporaire
|
||||
du runner ont été nettoyés au test suivant ; leurs chronométrages restent dans
|
||||
le journal intégral. Archiver `mods/sanctuary/build/run/clientGameTest/loading063/`
|
||||
avant de relancer un parcours pour conserver tous les profils.
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack` réussit en **2 min 22 s**,
|
||||
avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
|
||||
-PsanctuaryGameplay063ClientTests=true -PsanctuaryQuickTests=true
|
||||
-PsanctuaryClientNoVsync=true`. Les tests serveur dédiés restent exclus, selon
|
||||
le refus antérieur d'accepter leur EULA ; les huit ouvertures ci-dessus utilisent
|
||||
le serveur intégré au client natif et vérifient réellement les règles côté serveur.
|
||||
|
||||
Les deux archives locales sont vérifiées : dépendances exactes, ZIP, identité
|
||||
des **1 628 classes compilées**, ressources, absence de classes de test, même
|
||||
contenu normal/Test sauf le module rapide. Le JAR, les classes d'introduction,
|
||||
les ressources et les sons non concernés sont comparés à beta.062 ; le terrain
|
||||
et toute la séquence d'introduction restent identiques. Les anciens packs
|
||||
beta.062 sont conservés avec leurs empreintes originales.
|
||||
|
||||
- [Pack normal beta.063](../build/Sanctuary-beta.063.mrpack), SHA-256
|
||||
`1af1ff168f5cf97d7f44bb28398eb79efae8e1c4858f05d5b4291b1dfe48ad93`.
|
||||
- [Pack Test beta.063](../build/Sanctuary-Test-beta.063.mrpack), SHA-256
|
||||
`405a55e76233c8403f27320f104e09ee590cae652b97b4396dd6a5b1a7dd0531`.
|
||||
|
||||
Reçu `build/loading063-artifact.json`, build `build/loading063-check.log`.
|
||||
Pas de déploiement Prism, de changement de canal ou de sauvegarde personnelle.
|
||||
@@ -0,0 +1,136 @@
|
||||
# Menus Sanctuary — organisation
|
||||
|
||||
Cadrage du 15 septembre 2026, à partir de beta.077.
|
||||
Branche documentaire initiale : `codex/menu-architecture`.
|
||||
**Statut : organisation appliquée en [beta.083](menu-organization-beta083.md).
|
||||
Le renommage Combats / Battles a été livré en [beta.078](combat-beta078.md).**
|
||||
|
||||
Objectif : retrouver une pause compacte, avec une rubrique par intention et
|
||||
des sous-pages cohérentes. Conserver les composants Minecraft, les textures
|
||||
existantes et le retour vers l’écran d’origine.
|
||||
|
||||
## Pause
|
||||
|
||||
Reprendre la partie occupe toute la première ligne. Les rubriques suivent :
|
||||
|
||||
| Colonne gauche | Colonne droite |
|
||||
| --- | --- |
|
||||
| Découvertes / Discovery | Progression / Progression |
|
||||
| Monde / World | Habitant / Inhabitant |
|
||||
| Factions / Factions | Combats / Battles |
|
||||
|
||||
Options et Options du monde restent dessous, puis Sauvegarder et quitter ou
|
||||
Déconnexion. Les entrées séparées Progrès et Statistiques sont déplacées dans
|
||||
Progression et Découvertes. Monde ouvre toujours directement la carte.
|
||||
Combats regroupe duels et arènes et reste un accès direct, conformément au
|
||||
choix déjà confirmé.
|
||||
|
||||
**Économie est différée à la demande du créateur : aucun bouton économique,
|
||||
même désactivé, n’est prévu dans cette première passe.**
|
||||
|
||||
## Découvertes : ce que je connais et ce que j’ai fait
|
||||
|
||||
Un seul bandeau de catégories accueille le catalogue et
|
||||
les statistiques correspondantes :
|
||||
|
||||
| Catégorie FR / EN | Contenu cible |
|
||||
| --- | --- |
|
||||
| Général / General | Statistiques générales vanilla : temps, déplacements, morts et autres compteurs existants. |
|
||||
| Blocs / Blocks | Catalogue de blocs découverts, avec les compteurs disponibles : minés, posés, etc. |
|
||||
| Objets / Items | Objets connus, avec leurs compteurs disponibles : fabriqués, utilisés, récupérés, etc. |
|
||||
| Créatures / Mobs | Créatures découvertes et statistiques vanilla de rencontres mortelles : tuées et morts causées. |
|
||||
| Recettes / Recipes | Recettes révélées et collections qui permettent de les débloquer. |
|
||||
|
||||
Les statistiques d’un objet ou d’une créature sont accessibles dans sa fiche,
|
||||
sans imposer d’ouvrir un second catalogue. Les compteurs vanilla et Sanctuary
|
||||
gardent leur sens et leur source ; ne pas inventer un compteur absent ou
|
||||
additionner deux compteurs décrivant la même action.
|
||||
|
||||
À la première ouverture, conserver l’entrée actuelle sur les blocs possédés.
|
||||
Les filtres de connaissance et l’aptitude Catalogue restent en vigueur :
|
||||
« Tout » signifie tout ce qui est déjà découvert, jamais les éléments inconnus.
|
||||
Les statistiques ne deviennent pas une voie de contournement de ces règles.
|
||||
Les outils opérateur restent invisibles et désactivés en mode normal.
|
||||
|
||||
La beta.083 réunit les cinq catégories. Objets reprend les découvertes et
|
||||
les compteurs existants ; Créatures s’appuie sur les victimes et les morts
|
||||
causées. Les simples observations de créatures ne sont pas enregistrées dans
|
||||
les sauvegardes actuelles et ne sont donc pas présentées comme connues.
|
||||
|
||||
## Progression : où je vais et ce que je débloque
|
||||
|
||||
- Le titre et le nombre de niveaux disponibles ont une ligne réservée.
|
||||
- À gauche, un accès **Progrès / Advancements**, au-dessus des six compétences.
|
||||
Il ouvre l’arbre Minecraft existant et conserve le suivi des objectifs.
|
||||
- Sous cet accès, les compétences gardent leurs barres d’XP, leurs coûts et
|
||||
leurs commandes d’achat. Le remboursement opérateur reste conditionné
|
||||
aux permissions.
|
||||
- À droite, les **Aptitudes / Abilities** restent à leur place, avec leur
|
||||
propre défilement.
|
||||
- **Prestige / Prestige** et **Historique / History** occupent une rangée
|
||||
dédiée, indépendante du compteur d’XP. L’historique conserve les achats,
|
||||
remboursements et événements personnels existants.
|
||||
- Factions disparaît de cette navigation. Les sous-pages Prestige et
|
||||
Historique ne doivent pas recréer l’ancien trio Prestige–Factions–Historique.
|
||||
|
||||
L’arbre de Progrès conserve son écran complet : l’imbriquer dans la colonne
|
||||
des compétences rendrait les deux illisibles. « Au-dessus des compétences »
|
||||
désigne ici son accès, pas un arbre miniature.
|
||||
|
||||
### Chevauchement corrigé en beta.083
|
||||
|
||||
Les boutons Prestige, Factions et Historique occupaient la même ligne que
|
||||
les niveaux disponibles. La beta.083 réserve une ligne au compteur, puis
|
||||
une rangée à Prestige / Historique, avant les deux colonnes de contenu.
|
||||
|
||||
## Monde, Habitant, Factions et combats
|
||||
|
||||
**Monde** conserve l’accès direct à la carte et ses réglages. **Habitant**
|
||||
reste la fiche personnelle : nom, bio, prestige, faction, personnage et
|
||||
familier. Le nom de faction peut ouvrir la même page Factions que la pause.
|
||||
|
||||
**Factions** devient une destination dédiée : ma faction, membres,
|
||||
invitations, capacité, gestion et journal de faction. Sans faction, cette
|
||||
page présente la création et les invitations reçues. La navigation ne change
|
||||
ni les coûts ni les règles existantes : dix niveaux pour créer, deux places
|
||||
initiales, extensions liées aux charges de prestige.
|
||||
|
||||
**Combats** conserve sa liste publique de duels et arènes, les inscriptions, règles et
|
||||
paris actuels. Les mises en objets existantes ne nécessitent pas de créer
|
||||
l’économie générale pour fonctionner.
|
||||
|
||||
## Idées économiques conservées pour plus tard
|
||||
|
||||
Le créateur souhaite à terme une entrée Économie rassemblant le marché,
|
||||
la banque, la bourse, la loterie, les navets, le marché noir, les offres,
|
||||
requêtes et contacts. Aucun de ces services n’est implémenté par ce cadrage.
|
||||
|
||||
Proposition à reprendre ultérieurement : un tableau d’affichage commun aux
|
||||
missions, contrats, projets et annonces, relié aux habitants et aux factions.
|
||||
Une fiche indique l’auteur, le besoin, la récompense éventuelle et l’état ;
|
||||
des liens ouvrent le même contenu depuis chaque rubrique concernée.
|
||||
Courrier et contacts permettent de se répondre dans une présentation proche
|
||||
des livres, panneaux et inventaires Minecraft. La texture de courrier
|
||||
mentionnée par le créateur reste à retrouver ou recevoir avant intégration.
|
||||
|
||||
Ne pas fixer ici une nouvelle monnaie, un transfert automatique d’objets,
|
||||
une banque sans risque ou les conditions d’un contrat. La vision contient
|
||||
déjà des intentions sur les trois gemmes, la mailbox, le coffre-fort et les
|
||||
navets du dimanche ; elles devront être conciliées dans un ticket dédié.
|
||||
|
||||
## Première passe vérifiable
|
||||
|
||||
1. Réorganiser la pause et séparer Factions de la navigation personnelle.
|
||||
2. Réserver une ligne aux niveaux disponibles ; placer l’accès Progrès
|
||||
au-dessus des compétences, en conservant les aptitudes à droite.
|
||||
3. Rattacher les statistiques à Découvertes en conservant tous les accès
|
||||
existants, puis unifier les catégories selon les données disponibles.
|
||||
|
||||
Contrôler en français et en anglais, aux échelles GUI 2 et 3, avec retour
|
||||
Échap/Terminé vers le bon parent, textes longs, défilement, mode normal et
|
||||
opérateur. Vérifier le suivi des Progrès, les achats et remboursements,
|
||||
Prestige, invitations de faction et fermeture des arènes avant réponse réseau.
|
||||
Les nouveaux regroupements ne modifient ni sauvegardes ni transactions.
|
||||
|
||||
Le cadrage initial était documentaire. Sa livraison de code, ses limites et
|
||||
ses vérifications sont décrites dans [beta.083](menu-organization-beta083.md).
|
||||
@@ -0,0 +1,40 @@
|
||||
# beta.076 — navigation et pouvoirs sélectionnés
|
||||
|
||||
Branche `codex/menu-navigation-beta076`. Minecraft 26.3-pre-2 ; textures beta.070.
|
||||
|
||||
Le menu pause ouvre directement **Duels et arènes**. **Progression** contient
|
||||
les accès **Prestige**, **Factions** et **Historique**. La carte reste accessible
|
||||
par **Monde**. Les retours reviennent à l’écran d’origine.
|
||||
|
||||
L’historique regroupe les événements de prestige/faction et les achats ou
|
||||
remboursements du cycle actuel, avec les aptitudes conservées. Cette dernière
|
||||
liste était restée dans l’ancienne page Monde, devenue inaccessible depuis
|
||||
l’ouverture directe de la carte. Les achats des cycles terminés restent dans
|
||||
l’archive serveur : aucun nouveau format de sauvegarde ou réseau n’est ajouté.
|
||||
Les noms de faction invalides et invitations vides ne proposent plus un clic
|
||||
inutile. Le serveur conserve toutes ses validations et les confirmations.
|
||||
|
||||
« Usages historiques » devient **Choisir le pouvoir utilitaire**. Le mode
|
||||
sélectionné et son pouvoir sont visibles, le prérequis Lien actif est expliqué,
|
||||
et le contrôle affiché suit la touche configurée. La sélection ne lance pas
|
||||
le pouvoir : fermer le menu puis utiliser la touche (G par défaut). Les
|
||||
messages des pouvoirs utilitaires retrouvent leurs traductions propres.
|
||||
La dérogation opérateur existante est conservée.
|
||||
|
||||
Les arènes s’ouvrent immédiatement avec un état de chargement. Une réponse
|
||||
arrivée après fermeture ne rouvre plus l’écran.
|
||||
|
||||
## Vérification
|
||||
|
||||
Parcours client natif final réussi en 1 min 3 s : FR/EN, échelles 2/3, navigation,
|
||||
fermeture avant réponse, achats, fondation à deux places, annulation et
|
||||
confirmation de prestige, conservation de faction/aptitude, sélection utilitaire
|
||||
et message de recharge via G. Correction d’un rafraîchissement manquant lors
|
||||
de la réception du déblocage Lien actif. Le défilement est conservé lors
|
||||
d’un changement de pouvoir et ce comportement est aussi vérifié.
|
||||
Captures : `build/navigation076-evidence-final/`.
|
||||
|
||||
Ce lot est distribué avec beta.077 et sa couche de nuages, ajoutée à la
|
||||
demande du créateur pendant cette passe. Aucun pack beta.076 publié. Le build complet et les deux archives beta.077
|
||||
sont vérifiés ; voir [la livraison](cloud-vortex-beta077.md).
|
||||
Aucun déploiement personnel. Pas de serveur dédié (EULA non autorisée).
|
||||
@@ -0,0 +1,108 @@
|
||||
# beta.083 — organisation des menus
|
||||
|
||||
Application du [plan des menus](menu-architecture.md), sur la branche
|
||||
`codex/menu-organization-beta083`.
|
||||
|
||||
## Navigation
|
||||
|
||||
La pause conserve Reprendre, puis trois rangées de deux rubriques :
|
||||
Découvertes / Progression, Monde / Habitant, Factions / Combats.
|
||||
Options, Options du monde et la sortie restent natifs, ainsi que les
|
||||
éventuels ajouts du serveur. Aucun accès Économie n’est ajouté.
|
||||
|
||||
Progression réserve une ligne aux niveaux disponibles, puis une rangée
|
||||
Prestige / Historique. Progrès ouvre l’arbre Minecraft complet au-dessus
|
||||
des compétences de gauche ; les aptitudes gardent leur défilement à droite.
|
||||
Les sous-pages Prestige et Historique ne proposent plus Factions.
|
||||
|
||||
Factions devient une entrée directe, avec gestion et journal de faction.
|
||||
Les coûts, confirmations, invitations, permissions et transactions restent
|
||||
inchangés. Le journal reprend les événements de faction autorisés par le
|
||||
serveur, y compris les événements personnels des anciennes factions.
|
||||
L’historique personnel conserve les achats, remboursements et événements
|
||||
déjà disponibles.
|
||||
|
||||
## Découvertes et statistiques
|
||||
|
||||
Un bandeau unique donne accès à Général, Blocs, Objets, Créatures et Recettes.
|
||||
Changer de catégorie conserve le même écran parent : Échap / Terminé revient
|
||||
directement à la pause, sans retraverser les catégories visitées. Les fiches
|
||||
de statistiques reviennent à leur liste.
|
||||
|
||||
- **Général** : tous les compteurs généraux natifs, avec leurs unités et
|
||||
leur format Minecraft (temps, distances, etc.).
|
||||
- **Blocs** : catalogue Sanctuary existant, par défaut sur Possédés,
|
||||
avec recherche, filtres et compteurs existants.
|
||||
- **Objets** : par défaut les objets portés, y compris extension et
|
||||
accessoires. L’aptitude Catalogue permet d’afficher également les objets
|
||||
déjà découverts. Une fiche présente fabrication, utilisation, casse,
|
||||
récupération et abandon, chacun avec son compteur natif distinct.
|
||||
Une recette révélée ne suffit pas à déclarer son résultat découvert.
|
||||
- **Créatures** : espèces déjà tuées ou ayant tué le joueur, avec leurs
|
||||
deux compteurs natifs. Les sauvegardes n’ont pas de registre persistant
|
||||
des simples observations de mobs ; cette limite est indiquée dans la
|
||||
page. Les créatures inconnues ne sont pas listées.
|
||||
- **Recettes** : catalogue et collections existants, avec le même contrôle
|
||||
d’accès à l’aptitude et aux recettes connues.
|
||||
|
||||
Les statistiques sont demandées au serveur à l’ouverture ou à l’actualisation,
|
||||
puis affichées après réception du paquet Minecraft. Aucun compteur n’est
|
||||
additionné à son équivalent Sanctuary. Aucun format de sauvegarde, règle
|
||||
de gameplay ou identifiant existant ne change.
|
||||
|
||||
## Hello World et arrivée
|
||||
|
||||
Hello World dessine un fond uni `#171717`, identique au préchargement, sans
|
||||
le panorama hérité de l’écran principal. À la réception de l’intro après
|
||||
Hello World, ce fond s’assombrit progressivement jusqu’au noir en une
|
||||
seconde. La séquence originale de 29,5 secondes commence ensuite intégralement.
|
||||
La musique reste liée à l’apparition du portail, et le flash d’arrivée reste
|
||||
inchangé. Rejouer l’intro en jeu conserve son départ noir habituel.
|
||||
|
||||
## Vérifications
|
||||
|
||||
`Menus083ClientChecks` est passé dans un client Minecraft 26.3-pre-2 natif :
|
||||
|
||||
- français / anglais, GUI 2 et 3, captures de la pause, des catégories,
|
||||
de Progression, de Factions et des fiches ;
|
||||
- six destinations de pause, accès direct à la carte et aux combats,
|
||||
fermeture conservée si une réponse d’arène arrive après Échap ;
|
||||
- catégories sœurs et retours vers leur parent ; objets portés avant
|
||||
Catalogue, objets déjà découverts après achat, objets et mobs inconnus
|
||||
toujours masqués ;
|
||||
- clic réel sur un Progrès pour activer/désactiver son suivi, arbre complet
|
||||
et retour dans Progression ;
|
||||
- achat de compétence, remboursement opérateur du dernier coût, visibilité
|
||||
des contrôles après activation/révocation native des commandes ;
|
||||
- création de faction avec annulation puis confirmation, deux places,
|
||||
journal de faction séparé des achats, historique avec remboursements ;
|
||||
- passage de prestige avec conservation de la faction et des aptitudes,
|
||||
remise des compétences à zéro, charge reçue une seule fois.
|
||||
|
||||
`Welcome083ClientChecks` est passé en 53 secondes. Les captures natives
|
||||
confirment le gris uniforme aux quatre coins, puis les valeurs RVB neutres
|
||||
23 → 19 → 12 → 4 → 0 pendant le fondu. Le test vérifie aussi l’intro complète,
|
||||
le départ musical au portail, le replay noir et la fin sans double validation.
|
||||
La passe native des menus a duré 1 min 30 s.
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
est passé en **2 min 38 s**, avec 124 tâches. Les sources du JAR et ses
|
||||
1 706 classes correspondent aux sorties vérifiées. La comparaison avec
|
||||
beta.082 confirme que seuls les écrans et leur intégration changent ; données,
|
||||
textures, resource pack beta.070 et classes serveur sont conservés.
|
||||
|
||||
Archives locales vérifiées :
|
||||
|
||||
| Archive | SHA-256 |
|
||||
| --- | --- |
|
||||
| `Sanctuary-beta.083.mrpack` | `83b98db727665ab29fc3f0070f1616d781d2995efde1d2d344b50436251300ee` |
|
||||
| `Sanctuary-Test-beta.083.mrpack` | `1aea33aecbf247088702a39229815a1365afa54b53ba91be06f70fb89e1e86d3` |
|
||||
|
||||
Le reçu est dans `build/menus083-artifact.json`, les journaux dans
|
||||
`build/menus083-client.log`, `build/welcome083-client.log` et
|
||||
`build/menus083-check.log`. Les archives beta.082 restent intactes.
|
||||
|
||||
Pas de déploiement dans une instance personnelle ni de publication du canal
|
||||
packwiz dans cette tâche. Le GameTest serveur dédié reste exclu conformément
|
||||
au refus précédent d’accepter son EULA ; les tests avec serveur intégré
|
||||
utilisent uniquement des mondes plats de développement.
|
||||
@@ -0,0 +1,102 @@
|
||||
# beta.090 — Passage à Minecraft Java 26.3
|
||||
|
||||
Ticket de migration du projet, branche `codex/minecraft-26-3-beta090`.
|
||||
|
||||
## Cible et contrat avant modification
|
||||
|
||||
Passage de `26.3-pre-2` à la version finale **26.3**, publiée le 15 septembre
|
||||
2026. Cible Java 25, Fabric Loader 0.19.5 et Fabric API 0.160.5+26.3.
|
||||
Sanctuary, Demeure, le profil Test et le fork JEI sont compilés pour la même
|
||||
version exacte. Le fork JEI devient `30.32.0-sanctuary.3`, avec sa provenance
|
||||
et son patch reproductible ; aucune substitution du catalogue Sanctuary par
|
||||
le JEI standard.
|
||||
|
||||
Cette livraison change les binaires du projet et les archives locales. Aucun
|
||||
monde existant ni instance personnelle n'est ouvert ou modifié. Pas de
|
||||
régénération, d'expansion activée ni de migration des schémas Sanctuary.
|
||||
Les identifiants restent stables. Les essais utilisent des mondes neufs et
|
||||
les graines documentées des parcours ; les algorithmes de génération
|
||||
Sanctuary ne sont pas modifiés. Les résultats de génération sur la nouvelle
|
||||
version sont validés par les contrôles existants, sans garantir l'identité
|
||||
binaire de tous les chunks générés par deux versions de Minecraft.
|
||||
|
||||
Le pack de textures reçoit une édition beta.090 pour déclarer la cible 26.3.
|
||||
Le format reste 97.1 et les images existantes sont conservées ; le manifeste
|
||||
et l'archive beta.070 restent immuables. Les anciens packs beta.089 restent
|
||||
également immuables.
|
||||
|
||||
## Sources vérifiées
|
||||
|
||||
- [Sortie officielle de Minecraft Java 26.3](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-3) : Java 25, données 121.0 et ressources 97.1.
|
||||
- [Manifeste Minecraft officiel](https://piston-meta.mojang.com/mc/game/version_manifest_v2.json) : entrée release 26.3, métadonnées et empreintes Mojang.
|
||||
- [Fabric Loader pour 26.3](https://meta.fabricmc.net/v2/versions/loader/26.3) : 0.19.5 stable.
|
||||
- [Fabric API 0.160.5+26.3](https://modrinth.com/mod/fabric-api/version/0.160.5+26.3) : version déclarée pour 26.3, JAR et empreinte épinglés dans packwiz.
|
||||
|
||||
## Adaptations
|
||||
|
||||
- Les cibles Minecraft/Fabric sont communes à Sanctuary, Demeure, Sanctuary Test
|
||||
et au fork JEI. Les métadonnées des JAR et les deux distributions reprennent
|
||||
ces versions ; Fabric API est épinglé par URL et empreinte.
|
||||
- Le bouton d'ouverture du dossier des plans utilise `Blaze3D.openPath` :
|
||||
l'ancien `Util.getPlatform().openPath` n'existe plus dans la version finale.
|
||||
- Le scénario client du catalogue utilise la règle actuelle « Allow Commands »
|
||||
pour activer puis révoquer le mode opérateur. Sa vieille attente d'un second
|
||||
bouton d'inspection est retirée ; aucune permission de production n'est changée.
|
||||
- Le rapport TerrainAtlas récupère la version Minecraft réellement exécutée.
|
||||
- Minecraft passe du DataVersion 5018 (pre-2) à 5023 (finale), protocole 777.
|
||||
Les schémas Sanctuary restent inchangés. Les caches de plans dérivés incluent
|
||||
déjà les versions des mods et de Minecraft dans leur identité : la nouvelle
|
||||
version recalcule ses plans sans réutiliser un cache de l'ancien moteur.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Les essais clients utilisent Minecraft **26.3** natif et des mondes de
|
||||
développement neufs, graine **42**. Aucun serveur dédié n'est lancé et aucune
|
||||
EULA n'est acceptée ; `:sanctuary:runGameTest` est explicitement exclu.
|
||||
|
||||
- Super pistons : états de collision client/serveur, six directions, versions
|
||||
normale/gluante, course, charge 108/109, obstacles, transport, sauvegarde et
|
||||
rechargement. Le correctif de collision beta.089 est conservé et retesté.
|
||||
- Multiblocs : navigation du Fût et recherche avec souris immobile, onglets du
|
||||
Fourneau, fermeture normale, stockage, cuisson et persistance. Le correctif
|
||||
beta.088 ne réintroduit pas de paquet de fermeture entre deux pages.
|
||||
- Catalogue JEI : découverte, familles de recettes débloquées par advancements,
|
||||
permissions opérateur et révocation, transfert réel depuis la sixième rangée,
|
||||
ressources FR/EN, prestige, mort puis rechargement du monde.
|
||||
- Monde Sanctuary : génération neuve, graine 42, introduction complète, cache
|
||||
écrit puis relu sans recalcul, corruption volontaire d'un cache de développement
|
||||
puis reconstruction. Les 217 053 écritures de blocs contrôlées, plans, géométries
|
||||
des fluides, butins et zones protégées restent identiques après les deux reprises.
|
||||
Le parcours natif passe en 3 min 35 s. À titre d'observation locale, la création
|
||||
avec introduction dure 147,4 s, la reprise avec cache 2,7 s et la reprise après
|
||||
corruption 40,5 s ; ces parcours ne constituent pas un benchmark comparable.
|
||||
|
||||
Les journaux locaux des quatre parcours sont
|
||||
`build/migration090-{piston,multiblocks,recipes,world}-client.log`.
|
||||
|
||||
## Assemblage vérifié
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
passe sous Java 25 : **124 tâches**, en 2 min 53 s. Les quatre parcours clients
|
||||
séparés passent également. Les deux exports packwiz sont vérifiés après écriture.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.090.mrpack) — SHA-256
|
||||
`4cbb9c06126874ce4c767b5fb6b3bf61c2903784e908f030ebbfbc662aac4dfc`.
|
||||
- [Pack Test](../build/Sanctuary-Test-beta.090.mrpack) — SHA-256
|
||||
`ffe9f70ec0f17d567d0c108478ed90915eb5d8cdc407be9ba39860dd87adfc05`.
|
||||
- [Textures seules](../build/Sanctuary-Resource-Pack-beta.090.zip).
|
||||
- [Reçu de vérification local](../build/migration090-artifact.json).
|
||||
|
||||
Les JAR imbriqués, leurs cibles Minecraft, les archives de sources et les versions
|
||||
packwiz concordent. L'empreinte du JAR Fabric API téléchargé par Gradle correspond
|
||||
à celle de la dépendance packwiz. Les images, modèles, données et identifiants du
|
||||
JAR Sanctuary sont identiques à beta.089 ; seul le `pack.mcmeta` graphique change.
|
||||
La seule classe de production Sanctuary différente est `PlansScreen`. Les archives
|
||||
normal/Test beta.089 et les sources du manifeste graphique beta.070 sont conservées.
|
||||
|
||||
## Limites et distribution
|
||||
|
||||
Les clients testés sont natifs sur macOS, avec serveur intégré. Pas de validation
|
||||
Windows/Linux ou LAN à deux clients pour cette migration, ni de conversion d'une
|
||||
sauvegarde personnelle. Les archives locales n'avancent pas le canal packwiz et
|
||||
ne mettent pas à jour une instance Prism existante.
|
||||
@@ -0,0 +1,68 @@
|
||||
# beta.092 — Clic molette sur les super pistons
|
||||
|
||||
Branche `codex/multiblock-pick-beta092`, Minecraft 26.3.
|
||||
|
||||
## Contrat
|
||||
|
||||
Le clic molette sur un super piston renvoie le piston Minecraft d'origine :
|
||||
`minecraft:piston` pour le normal, `minecraft:sticky_piston` pour le gluant.
|
||||
Cela couvre les neuf socles, toutes les têtes et les tiges, dans les six
|
||||
orientations et à chaque profondeur de course. Une sélection reçue côté serveur
|
||||
pendant une transition de mouvement retrouve aussi le composant source.
|
||||
Les blocs techniques n'obtiennent pas d'objet dédié.
|
||||
|
||||
La sélection reste native : en créatif, un exemplaire ; en survie, sélection du
|
||||
piston déjà présent dans l'inventaire, sans création d'objet. Ctrl + clic molette
|
||||
ne copie pas les données techniques du contrôleur ou du piston mobile sur
|
||||
l'objet ordinaire. Le comportement des autres blocs et charges mobiles vanilla
|
||||
reste inchangé. Fourneau et Fût gardent leurs blocs source natifs, four et baril.
|
||||
|
||||
Aucun format de sauvegarde, identifiant, modèle, texture ou règle de génération
|
||||
n'est modifié. Aucun monde existant n'est ouvert ou migré.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Le parcours `Pick092ClientChecks` utilise un monde plat neuf de développement,
|
||||
graine 42 : tous les états client/serveur, puis de vrais clics molette sur des
|
||||
super pistons assemblés et étendus, en créatif et en survie.
|
||||
|
||||
Le parcours natif passe en **1 min 19 s** sur Minecraft 26.3/macOS :
|
||||
|
||||
- 864 états vérifiés côté client et serveur, avec et sans demande de données.
|
||||
- Douze combinaisons normal/gluant × six directions ; vrais clics molette sur
|
||||
chaque socle central, tête et les deux tiges du multibloc assemblé.
|
||||
- Le résultat est exactement un piston natif, avec les composants ordinaires.
|
||||
- En survie, un stack de cinq pistons présent est sélectionné sans duplication ;
|
||||
inventaire vide, aucun objet n'est créé.
|
||||
- Sélection des états mobiles d'extension/rétraction via le gestionnaire de paquet
|
||||
serveur natif. Ctrl + clic ne transporte pas le NBT du contrôleur ou du mouvement.
|
||||
- Les charges mobiles vanilla conservent leur comportement. Four et baril
|
||||
conservent aussi leur sélection native.
|
||||
|
||||
```sh
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryPick092ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Journal : `build/pick092-client.log`, marqueur `PICK092_PASS`.
|
||||
|
||||
## Livraison vérifiée
|
||||
|
||||
`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
passe en **3 min 1 s**, 124 tâches. Journal : `build/pick092-check.log`.
|
||||
Les exports correspondent aux JAR et à leurs sources. Textures, modèles,
|
||||
données, JEI et archives beta.091 sont conservés à l'identique.
|
||||
Reçu local : `build/pick092-artifact.json`.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.092.mrpack), SHA-256
|
||||
`3c1907fb3427e3df421eb84eb8f05c2e89c7cb3d27ef30d856602559cd33a383`.
|
||||
- [Pack Test](../build/Sanctuary-Test-beta.092.mrpack), SHA-256
|
||||
`a8acaffc0b803b81e12da7439af24abfb6dadfe890a952b6e89916317e9f4914`.
|
||||
|
||||
## Limites
|
||||
|
||||
Tests sur client natif macOS avec serveur intégré de développement ; pas de
|
||||
session LAN à deux clients pour cette livraison. Serveur GameTest dédié exclu,
|
||||
aucune EULA acceptée. Aucun déploiement dans une instance personnelle ni
|
||||
publication du canal packwiz.
|
||||
@@ -0,0 +1,98 @@
|
||||
# beta.084 — Clé dorée, Fût et Fourneau
|
||||
|
||||
Premier lot implémenté sur `codex/multiblocs-beta084`.
|
||||
Référence historique lue, sans modification : `../26.2/anotherworld`,
|
||||
`VaultStructure`, `SafeVaultMenu` et `SafeVaultScreen`. Reprise du repérage
|
||||
borné autour d'un centre et du contrôle serveur, pas du stockage monétaire,
|
||||
de la propriété privée ni de sa forme creuse à 26 composants.
|
||||
|
||||
## Contrat de sauvegarde et de migration — avant implémentation
|
||||
|
||||
Aucune génération ni conversion automatique d'une construction existante.
|
||||
L'assemblage est une action volontaire avec une clé dorée. Nouveau SavedData
|
||||
par dimension `sanctuary:multiblocks`, schéma 1 : origine du cube, type,
|
||||
orientation et identifiant UUID. Aucun contenu d'inventaire dans ce registre.
|
||||
Les 27 BlockEntities vanilla conservent leurs objets, composants, temps de
|
||||
cuisson, combustible restant et expérience. Les identifiants de blocs restent
|
||||
`minecraft:barrel` et `minecraft:furnace`. Le chargement d'une ancienne
|
||||
sauvegarde sans ce registre ne change rien : aucun fichier n’est écrit avant
|
||||
le premier assemblage. Le codec refuse un schéma inconnu et le chargeur refuse
|
||||
d’écraser un fichier illisible. La catégorie native de stockage NBT est
|
||||
`SAVED_DATA_COMMAND_STORAGE` ; les données métier restent dans notre codec.
|
||||
|
||||
Une dissociation retire seulement l'appartenance : elle ne restitue jamais
|
||||
une copie du stock initial. Une casse ou explosion laisse Minecraft déposer
|
||||
le contenu du composant cassé et dissout la machine ; les autres composants
|
||||
restent en place. Une partie déchargée suspend l'accès commun et la chauffe,
|
||||
sans chargement forcé ni rattrapage hors ligne. À la reprise, validation des
|
||||
27 composants. Les sauvegardes suivent l'atomicité native des chunks ; ce
|
||||
lot n'ajoute pas de journal transactionnel inter-chunks en cas de crash brutal.
|
||||
Les anciens inventaires ouverts sont fermés à l'assemblage/dissociation.
|
||||
|
||||
## Gestes et valeurs de la première version
|
||||
|
||||
- Clé : recette de trois lingots d'or en tête et un bâton en manche, sans usure.
|
||||
- Clic droit sur 27 barils ou fours en cube plein : repérage et confirmation
|
||||
par un deuxième clic dans les dix secondes. Une forme ambiguë est refusée.
|
||||
- Maj + clic droit sur une machine assemblée : dissocier.
|
||||
- Maj + clic droit sur un four ou baril indépendant : tourner, en conservant
|
||||
ses données. Pas de rotation d'une machine chargée.
|
||||
- Clic droit sans clé sur une façade : ouvrir le stock commun public.
|
||||
- Fût : 729 cases physiques, 54 par page, recherche par nom et identifiant.
|
||||
Les noms localisés sont résolus côté client en identifiants d’objets, puis
|
||||
filtrés uniquement dans le stock accessible validé par le serveur. Le
|
||||
Maj-clic de dépôt utilise tout le stock, même pendant une recherche.
|
||||
Une recherche fige ses emplacements jusqu'à la prochaine recherche.
|
||||
Changer de page/recherche ouvre un nouvel identifiant de menu et exige un
|
||||
curseur vide ; les anciens paquets de clic ne peuvent pas viser une autre page.
|
||||
- Fourneau : les 27 entrées, combustibles et sorties natifs, trois vues.
|
||||
Jusqu'à 27 cuissons simultanées à vitesse vanilla, avec chaleur partagée.
|
||||
Chaque cuisson paie un tick de combustible par tick de travail : le débit
|
||||
augmente, pas le rendement par charbon. Les combustibles et leurs restes,
|
||||
les recettes et l'XP restent gérés par le four vanilla. Pas de recette
|
||||
culinaire It's Alive dans ce lot. Une panne de combustible met le travail
|
||||
en attente sans effacer sa progression ; ajouter du combustible le reprend.
|
||||
Le débit correspond aux 27 fours physiques, sans multiplicateur de minerai.
|
||||
- Trémies : stock commun du Fût ; Fourneau, entrées en haut, combustible
|
||||
latéral, résultats en bas, en respectant les règles natives des seaux.
|
||||
- Apparence : composants vanilla conservés ; les fours montrent leur chauffe.
|
||||
Aucune nouvelle grande texture de façade dans cette première livraison.
|
||||
|
||||
## Vérifications
|
||||
|
||||
`Multiblocks084ClientChecks` tourne dans un nouveau monde plat intégré :
|
||||
confirmation volontaire, refus de chevauchement, cube traversant une frontière
|
||||
de chunks, fichier SavedData écrit puis relu, schéma inconnu, sérialisation
|
||||
native des objets nommés et de la cuisson, deux joueurs serveur dont un invité
|
||||
automatisé, trémies natives, inventaire plein, recherche localisée, pagination,
|
||||
curseur plein et paquet périmé, dissociation, casse et explosion avec conservation
|
||||
du stock. Cuisson : deux recettes simultanées, rendement du charbon partagé,
|
||||
sortie pleine, seau de lave/éponge mouillée, résultat natif/XP et panne puis
|
||||
reprise des 27 cuissons. Captures natives en FR/EN aux échelles 2 et 3.
|
||||
|
||||
Validation finale réussie : `check build assemblePack assembleTestPack`
|
||||
et `:sanctuary:runClientGameTest`, en excluant `:sanctuary:runGameTest`
|
||||
(serveur dédié/EULA non autorisés). 131 tâches, 105 exécutées, en 3 min 16 s.
|
||||
Le dernier scénario couvre aussi les six rangées, le dépôt depuis la rangée
|
||||
supplémentaire et le maintien des menus voisins sans lien avec la machine.
|
||||
|
||||
Archives locales : `build/Sanctuary-beta.084.mrpack` et
|
||||
`build/Sanctuary-Test-beta.084.mrpack`. Journaux :
|
||||
`build/multiblocs084-check.log` ; reçu d’intégrité :
|
||||
`build/multiblocs084-artifact.json`. Pack de textures beta.070 inchangé.
|
||||
Le canal publié reste inchangé.
|
||||
|
||||
Pour essayer rapidement : fabriquer la clé avec le motif `G G / G / S `
|
||||
(G = lingot d’or, S = bâton), ou obtenir `sanctuary:golden_wrench` en mode
|
||||
opérateur. Construire un cube plein de 27 barils ou de 27 fours et cliquer
|
||||
deux fois avec la clé. Maj-clic avec un autre bloc permet toujours d’en poser
|
||||
un contre la façade, notamment une trémie.
|
||||
|
||||
Limites de cette livraison : façade composée des blocs vanilla ; comparateurs
|
||||
sur le contenu du composant physique ; commandes de chauffe avancées et
|
||||
recettes composées différées. La sauvegarde est vérifiée par relecture disque
|
||||
et sérialisation native, pas par redémarrage complet d’une session à deux
|
||||
clients. Le déchargement réel d’une moitié de machine pendant un transfert
|
||||
reste à éprouver manuellement ; le refus d’accès aux chunks absents est testé.
|
||||
Aucun serveur dédié démarré, aucune EULA acceptée, aucun déploiement Prism
|
||||
ou monde personnel modifié.
|
||||
@@ -0,0 +1,204 @@
|
||||
# Multiblocs — reprise du catalogue
|
||||
|
||||
**Cahier rouvert le 15 septembre 2026. Conception, aucune machine livrée ici.**
|
||||
Le créateur demande de reprendre **tout le catalogue** avant de choisir un
|
||||
premier appareil. Ce document remet les décisions historiques à portée de la
|
||||
bêta ; les propositions nouvelles restent indiquées comme telles.
|
||||
Le [ticket MB-01](multiblocs-ticket.md) suit ce cadrage et prépare les lots de code.
|
||||
|
||||
**Reprise du 16 septembre 2026 : le premier duo choisi est Fourneau + Fût.**
|
||||
La séance porte sur leur conception avant intégration. Le créateur confirme
|
||||
ensuite l'inclusion de la clé, le Fût à 729 cases avec recherche et pages et
|
||||
le principe des fournées à combustible commun. Les gestes de la clé et les
|
||||
détails de chauffe restent ouverts ; les autres appareils restent au catalogue
|
||||
pour plus tard. Le créateur précise ensuite que tout It's Alive sera fusionné
|
||||
dans Sanctuary, mais ultérieurement ; le Fourneau pourrait remplacer sa
|
||||
cuisinière. Voir le [cadrage corrigé](multiblocs-itsalive-contrat.md).
|
||||
|
||||
Les huit propositions de la [recherche du 15 septembre](multiblocs-recherche.md)
|
||||
ont été **rejetées par le créateur**, jugées sans intérêt ou contraires au
|
||||
contrat Minecraft Vanilla. Le travail reprend sur le catalogue antérieur
|
||||
ci-dessous ; cette recherche ne constitue pas une liste d'implémentation.
|
||||
|
||||
## Les dossiers retrouvés
|
||||
|
||||
La source principale est le [cahier des machines que l'on construit](../../sanctuary-conception/docs/machines-multiblocs.md),
|
||||
dans le chantier de conception WG-26. Sa dernière modification est le commit
|
||||
`0e95da36ae7ebc99be5768a2f51e7be65aaf6702`, du 11 septembre 2026 :
|
||||
« valider l’assemblage volontaire avec la clé dorée ». Le fichier consulté
|
||||
ne comporte pas de modification locale.
|
||||
|
||||
Les dossiers complémentaires sont :
|
||||
|
||||
- [Redstone Language — ensemble](../../sanctuary-conception/docs/redstone-language-extensions.md) :
|
||||
catalogue des composants, transport, capteurs et connexions.
|
||||
- [Fiches des composants](../../sanctuary-conception/docs/redstone-language-composants.md) :
|
||||
contrôleur, terminal, afficheur et disquettes.
|
||||
- [Langage et machines](../../sanctuary-conception/docs/langage-et-machines.md) :
|
||||
programmation et installation d'expansion Galactium.
|
||||
- [Vision historique](../../sanctuary-conception/docs/vision.md) et
|
||||
[backlog historique](../../sanctuary-conception/docs/backlog.md) : recoupement
|
||||
des choix retenus et des propositions.
|
||||
|
||||
Ces liens pointent vers un autre worktree local. Le commit source est conservé
|
||||
pour retrouver la référence si ce worktree est déplacé. Les dossiers historiques
|
||||
restent consultés en lecture seule. Ils décrivent de la conception ; leur
|
||||
présence ne prouve pas une implémentation dans la bêta actuelle.
|
||||
|
||||
## Le principe déjà retenu
|
||||
|
||||
**Des blocs identiques réunissent leur fonction dans une construction plus grande.**
|
||||
Le joueur pose les composants, les assemble volontairement à la clé dorée,
|
||||
utilise une machine commune, puis peut retrouver ses blocs indépendants.
|
||||
|
||||
- **La pose ne fusionne rien.** Un cube de fours peut rester une batterie de
|
||||
fours ; neuf hoppers voisins peuvent garder neuf circuits.
|
||||
- **La clé à molette dorée assemble, dissocie et oriente.** Ces fonctions sont
|
||||
retenues ; recette, obtention, usure et gestes précis restent ouverts.
|
||||
- **Dissocier laisse les composants sur place.** La machine ne se transforme
|
||||
pas implicitement en un objet transportable. La séparation persiste après
|
||||
rechargement, même si la forme reste complète.
|
||||
- **Le stock actuel est conservé une seule fois.** Dissocier ne restaure pas
|
||||
des ingrédients déjà consommés. La répartition entre composants est à définir.
|
||||
- **L'usage local suffit.** Four, collecte ou musique restent utilisables sans
|
||||
ordinateur ; la programmation pourra coordonner les appareils.
|
||||
|
||||
## Catalogue principal
|
||||
|
||||
« Retenu » désigne une décision consignée dans l'ancien cahier, encore ouverte
|
||||
à une révision explicite pendant cette séance. Cela ne signifie pas « codé ».
|
||||
|
||||
| Appareil | Construction / fonction retenue | Ce qui reste à concevoir |
|
||||
| --- | --- | --- |
|
||||
| **Fourneau** — nom proposé | **27 fours ordinaires**, cube plein **3 × 3 × 3** ; chauffe commune, fournées et recettes à chaud. | Façade, orientation, entrées/sorties, chaleur, capacité, durée, rendement et première recette composée utile. |
|
||||
| **Fût** — nom retenu | **27 barils**, cube plein **3 × 3 × 3** ; stockage commun par pages et/ou défilement. | Capacité réelle, pagination, dessin, faces d'accès et répartition au démontage. |
|
||||
| **Grand baril de fermentation** — nom retenu | Plusieurs stacks d'**une même recette**, éventuellement à plusieurs ingrédients. | Composants, forme, volume, proportions du lot, conditions, vieillissement et temps hors ligne. |
|
||||
| **Présentoirs** — nom proposé | **9 objets par face de bloc**, **81 par façade 3 × 3**, **324 distincts sur quatre façades**. Une façade seule suffit. | Bloc support et fabrication, gestes de dépôt/retrait, modèles, consultation des cartes/plans, coût du rendu. |
|
||||
| **Méga-pistons** | **9 pistons en façade 3 × 3**, tête commune **3 × 3**, **course de 3 blocs** ; variante collante demandée. | Charge déplaçable, durée, collisions, traction, slime/miel, pièces déployées et interruption. |
|
||||
| **Trémie** — nom retenu | **9 hoppers à plat en 3 × 3**, surface de collecte commune et **45 cases**. Assemblage facultatif. | Sortie, débit, redstone, comparateur, insertion et orientations rendues au démontage. |
|
||||
| **Carillon** — nom retenu | Blocs musicaux **adjacents choisis**, pour accords et courtes séquences ; aucun carré ni nombre de neuf imposé. | Sélection, ordre, taille maximale, tempo, déclenchement, retour au début et réparation. |
|
||||
| **Métablit** — nom proposé par l'auteur | La fonction d'**établi collectif avec projet persistant** est une proposition. | Confirmer cette fonction, ses composants, sa grille et ce qu'elle apporte par rapport à l'établi et au crafter. |
|
||||
|
||||
### Fourneau : faire une fournée et transformer une recette
|
||||
|
||||
Les 27 fours forment un cube **plein**, centre compris. L'ancien four creux
|
||||
entouré de briques a été remplacé par ce choix. Le volume ne promet ni 27 fois
|
||||
la vitesse ni un multiplicateur de minerais.
|
||||
|
||||
L'ancien cahier propose deux usages explicites : **cuisson par lots**, avec
|
||||
les résultats des recettes admises, et **recette à chaud**, qui transforme
|
||||
ensemble plusieurs ingrédients. Neuf cases d'entrée et une réserve de
|
||||
combustible commune sont des propositions, pas des valeurs validées.
|
||||
Le premier alliage reste à choisir avec un objet utile auquel il sert.
|
||||
|
||||
L'ancien cahier prévoyait de reprendre le rôle du kitchen oven en conservant
|
||||
It's Alive autonome. **La direction actuelle remplace cette architecture :
|
||||
tout It's Alive sera fusionné dans Sanctuary, plus tard.** Le Fourneau pourrait
|
||||
alors remplacer la cuisinière, dont les usages précis restent à recenser.
|
||||
Concevoir le Fourneau pour pouvoir accueillir ces recettes ultérieurement ;
|
||||
le premier lot n'importe pas It's Alive et ne dépend pas d'une passerelle.
|
||||
|
||||
### Fût et fermentation : stockage et transformation
|
||||
|
||||
Le Fût conserve un stock fini, partagé entre toutes ses ouvertures ; changer
|
||||
de page ne change pas les objets accessibles à l'automatisation. **729 cases**,
|
||||
soit la somme des capacités de 27 barils ordinaires, ont été acceptées le
|
||||
16 septembre 2026, avec recherche et pages. Ce choix actuel ne provient pas
|
||||
de l'ancien cahier. La taille d'une page et l'intégration à l'inventaire
|
||||
Sanctuary restent à préciser.
|
||||
|
||||
La fermentation engage un lot d'une recette : les ingrédients ajoutés ensuite
|
||||
n'acquièrent pas rétroactivement son âge. Cette règle de lot est proposée dans
|
||||
l'ancien cahier. La composition du Fût n'est pas automatiquement celle de la
|
||||
cuve, et les règles du vin ne s'appliquent pas implicitement à la bière.
|
||||
|
||||
### Présentoirs : une collection réellement exposée
|
||||
|
||||
Les **81 objets d'une façade sont visibles ensemble**, sans pagination.
|
||||
Un angle peut présenter deux faces avec des contenus distincts ; dessus et
|
||||
dessous ne rajoutent pas implicitement des places aux 324 objets confirmés.
|
||||
Cartes, photos, plans, recettes, disquettes, disques et œufs étaient demandés.
|
||||
Un objet physique par emplacement est proposé ; accepter tous les autres
|
||||
objets reste à éprouver. La disponibilité des supports futurs ne doit pas
|
||||
être supposée dans la bêta.
|
||||
|
||||
### Méga-pistons : un mouvement commun
|
||||
|
||||
La tête parcourt réellement trois blocs. Les **27 cellules balayées** ne
|
||||
définissent pas une limite de 27 blocs poussables. L'ancien cahier propose
|
||||
un refus de tout le mouvement si une partie est bloquée et un démontage
|
||||
uniquement rétracté et immobile. Poids, traction et déplacement de conteneurs
|
||||
restent ouverts ; les états de neuf pistons indépendants ne suffisent pas
|
||||
à décrire cette mécanique.
|
||||
|
||||
### Trémie : collecter sur une surface
|
||||
|
||||
La proposition historique est **une sortie sous le centre**, raccordable à
|
||||
un hopper ordinaire pour poursuivre sur le côté. Cette sortie n'est pas encore
|
||||
retenue. Même distinction pour la commande : alimenter le centre pour bloquer
|
||||
toute la Trémie était proposé. **45 cases ne signifie pas débit multiplié par 9.**
|
||||
Une destination pleine doit laisser les objets dans la réserve ; une réserve
|
||||
pleine ne supprime pas les nouveaux drops.
|
||||
|
||||
### Carillon : construire un instrument
|
||||
|
||||
La forme libre adjacente remplace l'ancienne préférence pour une rangée.
|
||||
L'ordre de sélection comme ordre musical reste proposé. Le cahier compare :
|
||||
|
||||
- **Accord :** une impulsion joue les notes ensemble.
|
||||
- **Séquence :** une impulsion avance d'une note, avec tempo donné par la redstone.
|
||||
- **Variante à discuter :** une impulsion lance toute une phrase au tempo interne.
|
||||
|
||||
Chaque note garde son instrument, notamment son support propre. Les gestes
|
||||
d'accordage doivent rester accessibles. Le nombre de notes, les silences et
|
||||
la manière de réordonner la mélodie restent à concevoir.
|
||||
|
||||
## Pistes et installations voisines
|
||||
|
||||
| Piste | État retrouvé |
|
||||
| --- | --- |
|
||||
| **Veilleur** | Proposition : 9 observateurs en façade pour surveiller les positions devant eux et identifier laquelle a changé. |
|
||||
| **Batterie de distribution** | Proposition : 9 distributeurs en façade, sélection d'une bouche ou séquence avec leur stock réel. |
|
||||
| **Bassin de traitement, serre climatique, écluse, alambic** | En réserve ; pas automatiquement des assemblages de blocs identiques. |
|
||||
| **Presse à moule** | Écartée par l'auteur, fonction jugée déjà couverte par le crafter. |
|
||||
| **Afficheur programmable** | Cahier voisin : panneaux coplanaires, rectangle plein, texte continu et huit lignes par bloc de hauteur. Ses règles de regroupement ont leur propre contrat, à confronter à celles de la clé. |
|
||||
| **Installation Galactium** | Proposition voisine : construction autour d'un contrôleur, ressources et charge collective pour une expansion. Dépend du contrat d'expansion ; ne fait pas partie d'un premier appareil autonome. |
|
||||
|
||||
Le **terminal en titane reliant jusqu'à 128 coffres** est un réseau de stockage
|
||||
distinct du Fût. Le coffre 3 × 3 × 3 cité dans la discussion historique n'y a
|
||||
pas été identifié comme implémenté. Ces références ne deviennent pas de nouvelles
|
||||
machines validées par leur simple mention.
|
||||
|
||||
## Proposition pour reprendre la conception ensemble
|
||||
|
||||
Pour chaque appareil, partir de **ce que la construction change dans le jeu** :
|
||||
une chauffe partagée, un dépôt commun, une collection visible, une grande
|
||||
course, une surface de collecte ou une phrase musicale. Puis compléter une
|
||||
fiche courte :
|
||||
|
||||
1. **Construire :** blocs, forme, taille fixe ou variantes, orientation.
|
||||
2. **Reconnaître :** aspect assemblé, pièces actives, état visible, nom FR/EN.
|
||||
3. **Utiliser :** gestes, inventaire éventuel, recette ou commande, effet obtenu.
|
||||
4. **Raccorder :** faces d'entrée/sortie, hoppers et redstone.
|
||||
5. **Démonter :** casse, dissociation, récupération du contenu et reprise.
|
||||
6. **Progresser :** obtention, matériaux, intérêt par rapport aux blocs séparés.
|
||||
|
||||
Les trois premiers arbitrages transversaux proposés sont **l'aspect des blocs
|
||||
une fois réunis**, **les gestes de la clé** et **les tailles disponibles**.
|
||||
Le 3 × 3 et le 3 × 3 × 3 sont retenus pour certains appareils ; les étendre
|
||||
à toutes les machines effacerait le choix particulier du Carillon et des
|
||||
façades de collection. Aucun nouvel arbitrage n'est acquis à ce stade.
|
||||
|
||||
## État et vérification de cette reprise
|
||||
|
||||
Le catalogue et ses statuts ont été recoupés avec le cahier, la vision et le
|
||||
backlog de conception. La recherche ciblée dans les sources et les traductions
|
||||
de la bêta n'a pas retrouvé ces appareils sous leurs noms ; elle ne constitue
|
||||
pas un audit exhaustif de tout le code historique.
|
||||
La cible déclarée reste celle de `gradle.properties`, **26.3-pre-2** au moment
|
||||
de la lecture. Les anciennes vérifications d'API ne dispensent pas le futur
|
||||
ticket de vérifier ses usages sur cette version exacte.
|
||||
|
||||
Cette reprise modifie uniquement la documentation. Aucun build ni essai en
|
||||
jeu n'est nécessaire pour le catalogue ; les validations de gameplay figurent
|
||||
dans le ticket et seront exécutées lors des lots concernés.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Fourneau et It's Alive — fusion future dans Sanctuary
|
||||
|
||||
16 septembre 2026. Cadrage corrigé après clarification du créateur.
|
||||
Aucun portage, adaptateur ou changement de sauvegarde livré ici.
|
||||
|
||||
## Direction retenue
|
||||
|
||||
Le créateur souhaite intégrer **tout It's Alive dans Sanctuary**, mais
|
||||
**pas maintenant**. La proposition précédente de maintenir deux mods
|
||||
indépendants reliés par un module multiblocs partagé est abandonnée pour ce
|
||||
chantier. Aucune passerelle entre mods n'est un prérequis au premier lot.
|
||||
|
||||
Le lot actuel reste **clé dorée, Fourneau et Fût**. Le Fût à 729 cases avec
|
||||
recherche et pages et le principe du Fourneau à fournées et combustible commun
|
||||
sont retenus. Les gestes de la clé, la chauffe et les détails de fonctionnement
|
||||
restent à concevoir dans le ticket multiblocs.
|
||||
|
||||
## Place future du Fourneau
|
||||
|
||||
Le Fourneau **pourrait remplacer la cuisinière d'It's Alive** lors de la
|
||||
fusion. C'est la piste exprimée par le créateur (« je pense »), pas encore
|
||||
un remplacement détaillé et définitivement arbitré.
|
||||
|
||||
Ne pas réduire cette intention à la seule classe historique
|
||||
`KitchenOvenBlockEntity` : il faudra identifier précisément les usages de
|
||||
la cuisinière à reprendre au moment de la fusion. Les autres appareils,
|
||||
recettes et systèmes d'It's Alive seront examinés dans ce futur chantier.
|
||||
|
||||
Pour éviter une réécriture inutile, concevoir la cuisson du Fourneau de façon
|
||||
à pouvoir accueillir ultérieurement des recettes culinaires composées.
|
||||
Cette possibilité d'évolution n'impose aujourd'hui ni import de recettes,
|
||||
ni moteur culinaire complet, ni nouveau module autonome.
|
||||
|
||||
## Références techniques conservées pour plus tard
|
||||
|
||||
Le projet bêta charge Sanctuary, Demeure, JEI et le module de test ; It's
|
||||
Alive n'est pas déclaré dans `settings.gradle`.
|
||||
|
||||
La référence consultée en lecture seule est `../26.2/itsalive/` :
|
||||
|
||||
- son manifeste cible Minecraft `~26.2`, pas `26.3-pre-2` ;
|
||||
- `KitchenOvenBlockEntity` possède neuf cases d'ingrédients, une case de
|
||||
combustible et une sortie ;
|
||||
- `AbstractTimedCulinaryBlockEntity` recherche les recettes, calcule les lots,
|
||||
suit leur durée, consomme les ingrédients et produit les résultats.
|
||||
|
||||
Ces constats serviront à l'inventaire du futur portage, sans présumer que
|
||||
ce four constitue à lui seul toute la cuisinière visée par le créateur.
|
||||
La reprise des identifiants, des contenus déjà stockés et des travaux en
|
||||
cours devra recevoir son contrat de migration avant toute conversion.
|
||||
Les sources historiques et les sauvegardes restent inchangées.
|
||||
@@ -0,0 +1,290 @@
|
||||
# Multiblocs — recherche de compléments au catalogue
|
||||
|
||||
**Recherche du 15 septembre 2026, pour MB-01. Propositions rejetées par le créateur.**
|
||||
|
||||
**Décision après présentation :** les huit candidats sont écartés, jugés sans
|
||||
intérêt ou contraires au contrat Minecraft Vanilla. Le contenu ci-dessous est
|
||||
conservé comme historique de recherche, y compris son ordre proposé désormais
|
||||
sans valeur de sélection. Reprendre le [catalogue antérieur](multiblocs-conception.md)
|
||||
pour déterminer la liste d'implémentation ; ne pas réintroduire ces propositions
|
||||
comme candidates actives sans nouvelle demande du créateur.
|
||||
La demande est de compléter le [catalogue retrouvé](multiblocs-conception.md)
|
||||
avant de déterminer ensemble la liste d'implémentation. Aucune nouvelle entrée,
|
||||
forme, recette ou priorité ci-dessous n'est une décision du créateur.
|
||||
|
||||
## Conclusion proposée avant rejet — historique
|
||||
|
||||
Huit candidats méritent une discussion : **Atelier de taille, Alambic,
|
||||
Compostière, Citerne, Broyeur, Tisserie, Discothèque et Antenne sculk**.
|
||||
L'Alambic précise une piste déjà en réserve. La Citerne donne un usage de
|
||||
stockage au thème des bassins, distinct d'un bassin de transformation.
|
||||
|
||||
Je commencerais la sélection des ajouts par **Atelier de taille, Alambic et
|
||||
Compostière**, puis **Discothèque** pour un usage collectif musical. La
|
||||
**Citerne** devient intéressante si l'on souhaite des installations de liquides.
|
||||
Le **Broyeur** mérite un arbitrage sur les ressources avant d'être retenu.
|
||||
**Tisserie** et **Antenne sculk** ont un potentiel plus spécialisé à éprouver.
|
||||
|
||||
Leur intérêt vient respectivement des commandes de chantier, des préparatifs
|
||||
d'expédition, de la valorisation des récoltes, d'une programmation musicale,
|
||||
d'une réserve liquide, de transformations minérales, de motifs textiles et
|
||||
de la lecture des vibrations. Les rangs ci-dessus sont mon appréciation de
|
||||
conception, pas des mesures de popularité ou de temps de développement.
|
||||
|
||||
## Ce que les références apportent
|
||||
|
||||
Recherche dans les documents des projets et de Mojang. Les exemples attestent
|
||||
des principes de jeu ; **leur compatibilité avec Fabric 26.3-pre-2 n'a pas été
|
||||
évaluée et aucun de ces mods/plugins n'est proposé comme dépendance**.
|
||||
|
||||
| Référence consultée | Fait utile à la conception | Application proposée à Sanctuary |
|
||||
| --- | --- | --- |
|
||||
| [Create — Mechanical Crafter](https://github.com/Creators-of-Create/Create/wiki/Mechanical-Crafter), ancien wiki du projet, page de 2021 | Liaisons et direction se règlent à la clé ; des groupes adjacents peuvent rester distincts. | Faire voir l'appartenance et les raccords, garder les ingrédients lisibles dans la construction. |
|
||||
| [Create — Crushing Wheels](https://github.com/Creators-of-Create/Create/wiki/Crushing-Wheels), page de 2024 | Deux roues transforment des objets introduits entre elles, avec des recettes de broyage. | Donner au Broyeur un geste et une transformation identifiables ; choisir nos propres recettes et rendements. |
|
||||
| [Create — Mechanical Pump](https://github.com/Creators-of-Create/Create/wiki/Mechanical-Pump), page de 2021 | Pompage, sens et tuyaux assurent le transfert physique des fluides. | Distinguer réserve, transfert et transformation ; une Citerne seule n'est pas une pompe. |
|
||||
| [Botania — Botanical Brewery, dans le Lexicon](https://botaniamod.net/lexicon.html) | La préparation rassemble récipient, ingrédients et mana avant de produire un breuvage. | Montrer le lot engagé et son état dans un atelier ; mana et breuvages Botania ne sont pas repris. |
|
||||
| [CraftBook — Bridge](https://craftbook.enginehub.org/en/3.x/mechanics/bridge/) | Une construction de pont peut être commandée par panneau ou redstone. | Concevoir des usages architecturaux des méga-pistons : passage, porte et quai mobile. |
|
||||
| [Immersive Engineering — changelog 1.21.1](https://github.com/BluSunrize/ImmersiveEngineering/blob/1.21.1/changelog.md) | Le projet documente des corrections de pertes de contenu à la casse de machines et de problèmes de fluides au chargement des chunks. | Mettre conservation du contenu et reprise dans le premier scénario de réception, avant de multiplier les appareils. |
|
||||
|
||||
Ces anciens documents de Create sont utilisés comme références historiques de
|
||||
conception. Le [wiki GitHub annonce son déplacement](https://github.com/Creators-of-Create/Create/wiki)
|
||||
vers un nouveau site ; ses pages récentes n'ont pas été récupérées lors de cette
|
||||
recherche. Les descriptions ci-dessus ne prétendent donc pas résumer la dernière
|
||||
version distribuée de Create.
|
||||
|
||||
## Huit fiches candidates
|
||||
|
||||
Les gabarits et noms anglais sont proposés pour rendre les idées examinables.
|
||||
Ils restent modifiables. Tous les regroupements suivent la clé volontaire et
|
||||
la dissociation durable du catalogue. Aucun appareil ne fonctionne gratuitement
|
||||
du seul fait qu'il est plus grand.
|
||||
|
||||
### 1. Atelier de taille / Stoneworks
|
||||
|
||||
**Base vérifiée :** le tailleur de pierre transforme un matériau selon une
|
||||
recette choisie. [Présentation Mojang du tailleur de pierre](https://www.minecraft.net/de-de/article/block-week--stonecutter).
|
||||
|
||||
**Proposition :** neuf tailleurs de pierre en plateau **3 × 3** donnent un
|
||||
atelier de préparation de chantier. Le joueur prépare une commande avec
|
||||
plusieurs sorties et quantités : par exemple escaliers, dalles et murets dans
|
||||
la même pierre. L'atelier répartit les matériaux apportés entre les recettes,
|
||||
montre ce qui manque et s'arrête aux quantités demandées.
|
||||
|
||||
Le bénéfice est une commande persistante avec approvisionnement commun,
|
||||
utilisable à la main et par hoppers. Un raccord ultérieur aux besoins d'un plan
|
||||
peut préparer la liste, mais le premier atelier fonctionne par saisie manuelle.
|
||||
Il produit des objets ; les règles de pose et la compétence Construction
|
||||
continuent de s'appliquer lors du chantier.
|
||||
|
||||
**À décider :** nombre de lignes de commande, coût du travail, cadence et
|
||||
sorties. Réutiliser les recettes admises ; ne pas ouvrir silencieusement le
|
||||
catalogue encore inconnu du joueur. **Essai :** deux commandes concurrentes,
|
||||
stock insuffisant puis complété, sortie pleine, reprise sans surproduction.
|
||||
|
||||
### 2. Alambic / Brewing Array
|
||||
|
||||
**Base vérifiée :** l'alambic vanilla combine fioles et ingrédients avec du
|
||||
combustible. [Présentation Mojang de l'alambic](https://www.minecraft.net/en-us/article/taking-inventory--brewing-stand).
|
||||
|
||||
**Proposition :** neuf alambics en plateau **3 × 3** deviennent un atelier
|
||||
commun de potions. Préparer un lot homogène, afficher ses étapes, puis les
|
||||
enchaîner avec les ingrédients physiquement déposés. Exemple : préparer les
|
||||
potions de résistance au feu d'une expédition et les récupérer terminées.
|
||||
Une capacité de **27 fioles** est une proposition issue des trois fioles par
|
||||
composant, pas une capacité déjà approuvée.
|
||||
|
||||
Le regroupement doit apporter la préparation d'un lot et le suivi des étapes.
|
||||
Les recettes de potions et leurs effets restent ceux admis par le jeu.
|
||||
La fermentation alimentaire garde son propre appareil et sa temporalité.
|
||||
La forme et le rôle de cet Alambic précisent la piste ancienne sans l'imposer.
|
||||
|
||||
**À décider :** consommation par groupe de fioles, partage de chauffe,
|
||||
cadence et ordre des ingrédients. Une seule dose ne traite pas arbitrairement
|
||||
27 fioles. **Essai :** un lot partiel, ingrédient manquant au milieu, retrait
|
||||
pendant le cycle et redémarrage ; aucune étape ni consommation doublée.
|
||||
|
||||
### 3. Compostière / Composting Bed
|
||||
|
||||
**Base vérifiée :** le composteur accepte des matières végétales et produit
|
||||
de la poudre d'os ; leur efficacité varie. [Présentation Mojang du composteur](https://www.minecraft.net/en-us/article/block-month--composter).
|
||||
|
||||
**Proposition :** neuf composteurs à plat **3 × 3**, une réserve commune
|
||||
alimentée par les récoltes et une maturation visible. La construction reçoit
|
||||
un lot mélangé d'objets compostables ; la poudre d'os terminée est récupérée
|
||||
dans une sortie identifiée. Le travail peut accompagner un jardin partagé.
|
||||
|
||||
Le gain est la gestion d'un lot et la collecte de ses résultats, avec un
|
||||
remplissage lisible sur une grande surface. Le premier essai conserve les
|
||||
matières admises et compare le résultat à neuf composteurs indépendants.
|
||||
Un compost spécial, des engrais ou des sols enrichis seraient une extension
|
||||
à concevoir avec It's Alive ! ; ils ne sont pas requis pour cette première fiche.
|
||||
|
||||
**À décider :** progression commune ou neuf cellules de maturation derrière
|
||||
le stock commun, rendement, cadence et éventuel travail manuel.
|
||||
**Essai :** graines acceptées, objet non compostable refusé, mélange de stocks,
|
||||
sortie pleine et maturation conservée après déchargement.
|
||||
|
||||
### 4. Citerne / Cistern
|
||||
|
||||
**Base vérifiée :** les chaudrons stockent notamment eau et lave ; certaines
|
||||
fonctions de potions et de teinture de leur présentation appartiennent à
|
||||
Bedrock. [Présentation Mojang des chaudrons](https://www.minecraft.net/en-us/article/cauldron).
|
||||
|
||||
**Proposition :** neuf chaudrons en **3 × 3** forment une réserve commune
|
||||
avec niveau visible et point de puisage. Premier usage proposé : l'eau,
|
||||
apportée et retirée avec de vrais récipients. La lave serait un autre contenu
|
||||
admis, à décider avec son comportement de rupture. Un bassin unique conserve
|
||||
un seul contenu compatible ; aucune conversion d'un liquide en un autre.
|
||||
|
||||
La Citerne peut devenir le réservoir d'une cuisine ou d'un atelier de potions.
|
||||
Son intérêt augmente avec les futures connexions physiques ; stockage et
|
||||
pompage restent deux fonctions distinctes. La capacité ne doit pas seulement
|
||||
dupliquer celle d'un coffre de seaux sans avantage d'usage perceptible.
|
||||
|
||||
**À décider :** capacité, unités, pluie éventuelle, raccords, récipients et
|
||||
restitution au démontage. Les hoppers déplacent les objets récipients selon
|
||||
le contrat ; ils ne deviennent pas implicitement des tuyaux de liquide.
|
||||
**Essai :** remplir, prélever une quantité, reprendre après sauvegarde et
|
||||
dissocier sans créer de seaux ni déverser involontairement tout le stock.
|
||||
|
||||
### 5. Broyeur / Crusher
|
||||
|
||||
**Référence :** Create documente le broyage de cobblestone en gravier et de
|
||||
gravier en sable dans sa liste de transformations. [Crushing Wheels](https://github.com/Creators-of-Create/Create/wiki/Crushing-Wheels).
|
||||
|
||||
**Proposition :** deux rangées de trois meules, séparées par un passage,
|
||||
forment deux rouleaux qui traitent des matériaux déposés. Une autre forme
|
||||
compacte reste possible. Il s'agit d'une **nouvelle fonction** donnée aux
|
||||
meules assemblées, à valider explicitement : la meule vanilla n'est pas un
|
||||
broyeur de roche. Le trajet des objets explique visuellement la transformation.
|
||||
|
||||
Des granulats pour la construction seraient un premier usage. La mouture des
|
||||
aliments reste à coordonner avec le moulin déjà prévu dans It's Alive !.
|
||||
Recettes de recyclage, pigments et traitement des minerais sont des extensions
|
||||
distinctes ; aucun doublement de minerai n'est adopté par la référence à Create.
|
||||
|
||||
**Arbitrage central :** la chaîne pierre renouvelable → gravier → sable
|
||||
modifierait l'intérêt des gisements et de l'exploration dans Sanctuary.
|
||||
Décider si ce résultat est souhaité, puis choisir rendement et coût réel.
|
||||
**Essai :** bilan de matière d'une recette, cadence, arrêt et boucles de
|
||||
recyclage ; le retour ne doit pas fabriquer plus de matière qu'il n'en engage.
|
||||
|
||||
### 6. Tisserie / Textile Workshop
|
||||
|
||||
**Base vérifiée :** le métier à tisser applique des motifs et couleurs
|
||||
successifs aux bannières. [Présentation Mojang du métier à tisser](https://www.minecraft.net/en-us/article/block-week--loom).
|
||||
|
||||
**Proposition :** six métiers à tisser en façade **3 × 2** deviennent un
|
||||
atelier qui conserve une composition de motifs, ses couleurs et une commande
|
||||
de bannières. Plusieurs joueurs apportent supports, colorants et motifs ; la
|
||||
construction présente un grand aperçu et prépare la série demandée.
|
||||
|
||||
L'intérêt à éprouver est l'édition persistante d'une composition et son suivi
|
||||
matériel, par exemple pour une faction. Une simple copie de bannière ne suffit
|
||||
pas à justifier cette machine. Textile culinaire, tentures et nouveaux tissus
|
||||
ne deviennent pas des dépendances obligatoires de cette proposition.
|
||||
|
||||
**À décider :** avantage sur les outils de bannière existants, format du modèle,
|
||||
droits sur les motifs, consommation et lien avec les collections.
|
||||
**Essai :** réalisation d'un motif composé, réapprovisionnement et reprise ;
|
||||
une bannière rare ou un motif manquant ne doit pas être copié gratuitement.
|
||||
|
||||
### 7. Discothèque / Record Console
|
||||
|
||||
**Base vérifiée :** Minecraft Java permet déjà les interactions des hoppers
|
||||
et droppers avec les jukebox, ainsi qu'un signal pendant la lecture.
|
||||
[Notes officielles Java 1.19.4](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-19-4).
|
||||
|
||||
**Proposition :** plusieurs jukebox adjacents choisis, par exemple un meuble
|
||||
**3 × 2**, forment une collection écoutable avec ordre de lecture, prochain
|
||||
morceau, arrêt et répétition. Chaque disque reste un objet réel ; une seule
|
||||
lecture commune est émise. Le meuble pourrait montrer les disques disponibles.
|
||||
|
||||
La valeur est le choix et la modification d'une programmation musicale
|
||||
sur place. Le Carillon compose des notes ; la Discothèque joue des disques.
|
||||
Une simple boucle automatique serait trop proche des montages déjà possibles.
|
||||
|
||||
**À décider :** sélection du groupe, capacité, interface, commandes redstone,
|
||||
reprise du morceau et portée sonore. **Essai :** modifier la liste pendant
|
||||
l'écoute, rejoindre à deux joueurs, retirer le disque actif et casser un
|
||||
composant ; pas de musique fantôme ni de disque perdu.
|
||||
|
||||
### 8. Antenne sculk / Vibration Array
|
||||
|
||||
**Base vérifiée :** un capteur sculk calibré filtre les vibrations suivant
|
||||
un signal ; Mojang documente également la réémission avec l'améthyste.
|
||||
[Snapshot Java 23w12a](https://www.minecraft.net/de-de/article/minecraft-snapshot-23w12a).
|
||||
|
||||
**Proposition :** neuf capteurs calibrés en surface **3 × 3**, avec lecture
|
||||
commune des catégories reçues et petite mémoire des derniers événements.
|
||||
Plusieurs catégories peuvent être surveillées et affichées ensemble. Exemple :
|
||||
une porte réagit à une courte suite de gestes ; l'instrument permet de voir
|
||||
lequel a été reçu ou manque. La durée de mémoire reste bornée.
|
||||
|
||||
Le Veilleur observe des changements de blocs devant lui. L'Antenne apporte
|
||||
une lecture d'événements vibratoires ; elle ne révèle pas automatiquement le
|
||||
nom d'un joueur, ses coordonnées ou des lieux hors de portée. Le simple gain
|
||||
de rayon ne suffit pas à justifier neuf composants.
|
||||
|
||||
**À décider :** filtres, lecture visible, sorties et distinction avec un
|
||||
contrôleur branché sur des capteurs ordinaires. **Essai :** catégories distinctes,
|
||||
obstacles de laine, événements simultanés, boucles provoquées par la propre
|
||||
machine et expiration de la mémoire.
|
||||
|
||||
## Compléter les machines existantes avant de les multiplier
|
||||
|
||||
| Idée examinée | Recommandation pour notre catalogue |
|
||||
| --- | --- |
|
||||
| Grande fonderie, four à alliages, grand fumoir | Examiner d'abord les modes et recettes du **Fourneau** ; un autre bâtiment doit offrir un procédé distinct. |
|
||||
| Silo à matériau unique | Examiner un réglage du **Fût** avant d'ajouter un deuxième stockage volumineux. |
|
||||
| Table de fabrication géante | Préciser le **Métablit** ; le [crafter vanilla automatise déjà la fabrication](https://www.minecraft.net/en-us/article/crafting-crafter). Une grille plus grande demande des recettes et un usage propres. |
|
||||
| Pont rétractable, grande porte, élévateur court | En faire des montages de réception des **méga-pistons**, avec leur course de trois blocs. Un ascenseur à longue course demanderait un autre contrat. |
|
||||
| Mur de cartes, bibliothèque de plans | Éprouver les **présentoirs** et les plans existants avant de créer une table cartographique supplémentaire. |
|
||||
| Grand afficheur lumineux | Confronter à l'**afficheur programmable** déjà conçu ; ne pas créer deux systèmes d'écran par simple changement de nom. |
|
||||
| Presse à moule | Conserver le choix historique d'abandon. La présence de presses dans d'autres mods ne réouvre pas cette décision à elle seule. |
|
||||
| Serre qui accélère tout, carrière automatique, générateur de ressources | Réserver une conception propre avec coûts et conséquences sur exploration, métiers, progression et terrain. |
|
||||
|
||||
## Ancienne base de liste d'implémentation — non retenue
|
||||
|
||||
**Ordre conseillé, encore à choisir ensemble.** Chaque appareil reste un lot
|
||||
jouable autonome ; les groupes ci-dessous rapprochent les usages et dépendances.
|
||||
La clé arrive avec le premier appareil. Aucune branche de code n'est créée ici.
|
||||
|
||||
| Groupe proposé | Entrées | Pourquoi cet ordre / condition |
|
||||
| --- | --- | --- |
|
||||
| **1. Première construction** | **Clé dorée + Fût** | Éprouver assemblage volontaire, contenu commun, accès à deux et dissociation avec une fonction immédiatement utilisable. |
|
||||
| **2. Atelier quotidien** | **Trémie, Fourneau, Atelier de taille, Compostière** | Faire circuler, transformer et préparer les matériaux. Le Fourneau exige sa première recette composée utile et un choix de chauffe. |
|
||||
| **3. Lieux collectifs** | **Présentoirs, Carillon, Discothèque** | Donner des usages visibles aux collections et à la musique ; ces lots peuvent avancer indépendamment des recettes industrielles. |
|
||||
| **4. Préparation et liquides** | **Alambic, fermentation, Citerne** | Fixer les lots, consommations et règles de temps. La fermentation dépend du contrat culinaire ; l'Alambic peut fonctionner avec ses fioles sans attendre la Citerne. |
|
||||
| **5. Mécanismes** | **Méga-pistons, Veilleur, batterie de distribution** ; **Antenne sculk** à départager | Éprouver grandes constructions mobiles, observation et commandes. L'Antenne doit démontrer son apport face aux capteurs et au futur contrôleur. |
|
||||
| **6. Recettes et ateliers spécialisés** | **Broyeur, Métablit, Tisserie** | Choisir respectivement l'effet sur les ressources, le rôle du projet collectif et l'avantage d'une composition textile persistante. |
|
||||
|
||||
Les familles historiques retenues gardent leur statut ; les nouvelles entrées
|
||||
de cette table sont des candidates. Si la première livraison doit montrer
|
||||
prioritairement une transformation plutôt qu'un stockage, **Fourneau + clé**
|
||||
reste une alternative cohérente au Fût. Ce choix appartient à la prochaine
|
||||
discussion, pas à la recherche seule.
|
||||
|
||||
## Vérification de la cible et limites de l'étude
|
||||
|
||||
Lecture complémentaire du JAR de sources Minecraft **26.3-pre-2** déjà présent
|
||||
dans le cache Gradle local, sans copie des dépendances dans Git :
|
||||
|
||||
- `StonecutterMenu` : recettes à entrée unique, sélection et résultat natif.
|
||||
- `BrewingStandBlockEntity` : trois positions de fioles ; combustible lu via
|
||||
`DataComponents.BREWING_FUEL`, durée influencée par son multiplicateur.
|
||||
- `ComposterBlock` : couches apportées par le composant `Compostable` et son
|
||||
contexte, plutôt qu'une table d'efficacité à recopier depuis un vieux guide.
|
||||
- `CalibratedSculkSensorBlockEntity` : filtre de fréquence et rayon d'écoute
|
||||
local de 16 blocs ; aucune portée de multibloc décidée par cette lecture.
|
||||
- `JukeboxBlockEntity` : lecteur de morceau, objet conservé et données de reprise.
|
||||
|
||||
Ces lectures vérifient des points précis et ne constituent pas un prototype
|
||||
de multibloc ni une mesure de performance. Le modèle de chaudron de Bedrock
|
||||
n'est pas une preuve de comportement Java ; le futur contrat des liquides doit
|
||||
être vérifié sur la cible avant implémentation.
|
||||
|
||||
La recherche a porté sur les fonctions, les gestes, les recouvrements et les
|
||||
dépendances. Le coût relatif d'implémentation est une appréciation technique ;
|
||||
aucune estimation de durée ni compatibilité de mod externe n'est promise.
|
||||
Liens locaux et diff documentaire vérifiés. Aucun code ou binaire modifié.
|
||||
@@ -0,0 +1,153 @@
|
||||
# MB-01 — Cadrer le catalogue des machines multiblocs
|
||||
|
||||
**Ticket local ouvert le 15 septembre 2026 — conception en cours.**
|
||||
Le créateur demande de reprendre tout le catalogue avant de sélectionner le
|
||||
premier lot d'implémentation. Le [cahier de reprise](multiblocs-conception.md)
|
||||
conserve les sources, les anciennes décisions et les propositions ouvertes.
|
||||
|
||||
**Décision sur le complément :** les huit candidats de la
|
||||
[recherche sourcée](multiblocs-recherche.md) sont rejetés par le créateur,
|
||||
jugés sans intérêt ou contraires au contrat Minecraft Vanilla. Reprendre
|
||||
la liste antérieure ; les recommandations de cette recherche ne sont pas retenues.
|
||||
|
||||
Branche documentaire réservée : `codex/multiblocs-ticket`.
|
||||
Elle est créée ; le checkout de travail existant reste sur sa branche en cours.
|
||||
Aucun numéro `beta.xxx` réservé et aucune issue distante publiée.
|
||||
|
||||
## Ce que le joueur doit pouvoir faire à terme
|
||||
|
||||
Construire une machine à partir de blocs, choisir de les réunir avec la clé
|
||||
à molette dorée, bénéficier d'une fonction commune visible, puis retrouver
|
||||
les composants indépendants sans perdre ni dupliquer le stock actuel.
|
||||
Les blocs simplement voisins gardent leur fonctionnement individuel.
|
||||
|
||||
## Résultat vérifiable de ce ticket de conception
|
||||
|
||||
Obtenir un catalogue dont chaque entrée indique sa fonction, son statut,
|
||||
ses choix ouverts et un scénario jouable de réception. Compléter ensuite les
|
||||
fiches retenues et ouvrir des tickets d'implémentation autonomes avec leur
|
||||
branche. **MB-01 ne déclare pas toutes les machines prêtes à coder en un seul lot.**
|
||||
|
||||
**Sélection du 16 septembre 2026 : Fourneau et Fût.** Le créateur demande
|
||||
de réfléchir à leur intégration. Ce duo constitue le premier périmètre à
|
||||
concevoir ; aucun ordre de livraison entre les deux ni valeur de fonctionnement
|
||||
supplémentaire n'est encore validé. Branche de cette reprise documentaire :
|
||||
`codex/multiblocs-fourneau-fut-cadrage`.
|
||||
|
||||
Confirmation du créateur : **la clé dorée fait partie du premier lot**.
|
||||
Les cubes pleins de 27 fours et de 27 barils, la cuisson par fournées avec
|
||||
combustible commun et le Fût à **729 cases avec recherche et pages** sont
|
||||
acceptés. Les neuf entrées du Fourneau, ses durées, son débit, les gestes et
|
||||
la recette de la clé restent à préciser.
|
||||
|
||||
**Clarification : tout It's Alive sera intégré à Sanctuary ultérieurement,
|
||||
pas dans ce lot.** Le Fourneau pourrait alors remplacer la cuisinière ; le
|
||||
détail de ce remplacement reste à définir. Le [cadrage corrigé](multiblocs-itsalive-contrat.md)
|
||||
remplace la proposition de passerelle entre mods autonomes. Le premier lot
|
||||
multiblocs ne dépend pas d'un portage immédiat d'It's Alive.
|
||||
|
||||
## Périmètre à passer en revue
|
||||
|
||||
Fourneau, Fût, grand baril de fermentation, présentoirs, méga-pistons, Trémie,
|
||||
Carillon et Métablit. Réexaminer séparément Veilleur et batterie de distribution.
|
||||
Conserver les installations en réserve et les idées écartées avec leur statut.
|
||||
Rapprocher les contrats de l'afficheur et de Galactium lorsque nécessaire,
|
||||
sans imposer leur livraison aux machines utilisables localement.
|
||||
|
||||
## Décisions à produire avant les tickets de code
|
||||
|
||||
- [ ] Pour chaque entrée, confirmer maintien, révision, report ou abandon.
|
||||
- [x] Compléments de la recherche arbitrés : les huit propositions sont
|
||||
rejetées. Aucun de ces ajouts n'entre dans la liste d'implémentation.
|
||||
- [x] Premier périmètre sélectionné : Fourneau et Fût, le 16 septembre 2026.
|
||||
- [ ] Compléter les six rubriques de la fiche du cahier : construction,
|
||||
apparence, usage, raccords, démontage et progression. Distinguer les nombres
|
||||
retenus des valeurs d'essai, et donner les noms et libellés FR/EN nécessaires.
|
||||
- [ ] Fixer les gestes de la clé sans conflit entre tourner, sélectionner,
|
||||
assembler et dissocier ; décrire l'aperçu, l'annulation et les refus visibles.
|
||||
- [ ] Fixer obtention, recette et éventuelle usure de la clé. Définir les premiers
|
||||
blocs orientables, la conservation de leur état et les opérations admissibles.
|
||||
- [ ] Décider apparence après assemblage, orientations et éventuelles tailles
|
||||
supplémentaires, appareil par appareil.
|
||||
- [ ] Choisir un premier résultat jouable et rédiger son ticket d'implémentation
|
||||
avec valeurs d'essai, dépendances réelles et branche `codex/<sujet>`.
|
||||
|
||||
## Découpage d'implémentation proposé
|
||||
|
||||
Fourneau et Fût sont les deux lots retenus pour la conception de la première
|
||||
intégration. Les autres lignes restent des **lots candidats**, sans ordre de
|
||||
livraison validé ni sous-ticket distant publié. Le premier appareil livré emporte
|
||||
la clé et le contrat commun nécessaires à son usage réel ; éviter de livrer
|
||||
un mécanisme d'assemblage sans machine utilisable.
|
||||
|
||||
| Lot candidat / branche prévue | Résultat jouable et vérifiable |
|
||||
| --- | --- |
|
||||
| **Fourneau** — `codex/multibloc-fourneau` | Assembler 27 fours, cuire une fournée, retirer le résultat, arrêter/reprendre et dissocier. Chauffe et capacités à préciser. Prévoir l'accueil futur de recettes composées ; la fusion culinaire d'It's Alive est différée. |
|
||||
| **Fût** — `codex/multibloc-fut` | Assembler 27 barils, déposer et retrouver un stock commun sur plusieurs pages, l'utiliser à deux joueurs et avec un hopper, puis dissocier sans perte. |
|
||||
| **Fermentation** — `codex/multibloc-fermentation` | Engager plusieurs stacks d'une recette aux bonnes proportions, suivre le lot et récupérer une seule production. Dépend d'un contrat culinaire et temporel explicite. |
|
||||
| **Présentoirs** — `codex/multibloc-presentoirs` | Remplir une façade de 81 objets distincts visibles et quatre façades totalisant 324, consulter les supports admis et récupérer les objets d'un angle cassé une seule fois. |
|
||||
| **Méga-pistons** — `codex/multibloc-mega-pistons` | Commander une tête 3 × 3 sur une course animée de trois blocs, vérifier un obstacle intermédiaire, la variante collante et une interruption. |
|
||||
| **Trémie** — `codex/multibloc-tremie` | Choisir entre neuf circuits individuels et une collecte commune de 45 cases, constater la sortie et son débit, le verrouillage retenu et le cas d'une destination pleine. |
|
||||
| **Carillon** — `codex/multibloc-carillon` | Choisir un groupe adjacent, jouer un accord puis une courte séquence selon le mode retenu, réaccorder une note et garder un groupe voisin indépendant. |
|
||||
| **Métablit** — `codex/multibloc-metablit` | Si la fonction est retenue : préparer un projet persistant à deux joueurs, quitter/revenir, apporter les pièces manquantes et produire un résultat unique. |
|
||||
|
||||
## Contrat commun requis par la première implémentation
|
||||
|
||||
Le code reste côté serveur pour l'appartenance des composants, les stocks,
|
||||
les cycles et les opérations. Un bloc ne peut appartenir à deux machines.
|
||||
La reconnaissance des formes est bornée ; elle ne charge pas des chunks
|
||||
distants. Les protections effectivement présentes sont respectées.
|
||||
|
||||
Avant de créer des données persistantes, écrire un **contrat de sauvegarde
|
||||
et de migration explicite** : identité de machine, composants et orientations,
|
||||
contenu actuel, travail engagé, version, suspension et reprise. Charger une
|
||||
ancienne construction ne doit pas l'assembler. Définir le devenir des matières
|
||||
en cas de casse, d'explosion, de dissociation et d'interruption, ainsi que les
|
||||
opérations refusées. Un démontage impossible faute de place attend une
|
||||
récupération explicite ; il ne supprime pas le surplus.
|
||||
|
||||
Décharger une partie suspend le travail concerné sans produire deux fois ni
|
||||
rattraper silencieusement une durée hors ligne. Une éventuelle fermentation
|
||||
hors ligne reçoit son propre contrat. Le démontage conserve l'état courant,
|
||||
y compris les combustibles déjà dépensés et les résultats déjà obtenus.
|
||||
|
||||
La représentation technique des composants reste à choisir. Aucun nouveau
|
||||
registre ni renommage d'identifiant `sanctuary:*` n'est décidé par ce ticket.
|
||||
Les plans et les recettes accessibles conservent leurs responsabilités
|
||||
actuelles. La fusion future d'It's Alive ne rend pas ses fonctions disponibles
|
||||
dans ce lot du seul fait de la conception historique.
|
||||
|
||||
## Vérifications exigées des futurs lots
|
||||
|
||||
- [ ] Sans clé, poser une forme complète conserve ses blocs indépendants.
|
||||
Assembler, dissocier puis recharger conserve le choix explicite du joueur.
|
||||
- [ ] Une forme incomplète, un chevauchement, une mauvaise orientation ou un
|
||||
accès refusé donne une explication sans modification partielle.
|
||||
- [ ] Deux interactions simultanées, un transfert automatique et deux façades
|
||||
ouvertes travaillent sur le même stock ; aucune duplication de contenu.
|
||||
- [ ] Inventaires pleins, stocks préexistants, rupture, déchargement partiel,
|
||||
redémarrage et réassemblage conservent matières, état et résultats selon
|
||||
le contrat retenu. Tester aussi les composants répartis entre deux chunks.
|
||||
- [ ] Le scénario propre à la machine fonctionne en survie par la voie
|
||||
d'obtention retenue, avec interface FR/EN, puis à deux joueurs.
|
||||
- [ ] Les tests utiles et `./gradlew check build` passent. Si la distribution
|
||||
change, `./gradlew assemblePack` passe ; livraison et incrément mod/pack
|
||||
suivent [le versionnement](versioning.md). Aucun déploiement personnel
|
||||
n'est implicite dans ce ticket.
|
||||
|
||||
## État de la préparation
|
||||
|
||||
Catalogue retrouvé, décisions historiques recoupées, scénarios proposés et
|
||||
références locales vérifiées. Fourneau et Fût sélectionnés ; **leurs modalités
|
||||
de fonctionnement et les autres arbitrages ci-dessus restent ouverts.**
|
||||
La demande courante porte sur la conception : aucun code, binaire, monde ou
|
||||
format de sauvegarde modifié, aucun test de gameplay présenté comme exécuté.
|
||||
|
||||
## Livraison du premier lot — beta.084
|
||||
|
||||
La demande a évolué du cadrage à l’implémentation le 16 septembre 2026.
|
||||
Clé, Fût et Fourneau sont implémentés sur `codex/multiblocs-beta084` ; le
|
||||
[contrat de livraison](multiblocs-beta084.md) précise les valeurs retenues,
|
||||
la sauvegarde, les tests et leurs limites. Il remplace l’état documentaire
|
||||
« aucun code modifié » ci-dessus pour ce premier lot uniquement. Les autres
|
||||
multiblocs et la fusion It's Alive restent différés.
|
||||
+217
@@ -13,6 +13,223 @@ JAR Sanctuary sont des pièces jointes de releases Gitea. Aucun JAR de mod ou
|
||||
dépendance téléchargée n'entre dans l'historique Git. Le canal Beta est distinct
|
||||
de l'ancien pack 26.2.
|
||||
|
||||
## beta.092 — Clic molette des super pistons
|
||||
|
||||
Les packs locaux normal/Test beta.092 corrigent la sélection des composants
|
||||
de super piston. Dépendances et textures beta.090 conservées.
|
||||
[Contrat et vérifications](multiblock-pick-beta092.md). Aucun canal publié
|
||||
ni instance personnelle modifié.
|
||||
|
||||
## beta.091 — Interactions des passagers
|
||||
|
||||
Les packs locaux normal/Test beta.091 ajoutent les clics sur les animaux embarqués
|
||||
et permettent de les viser à l’arrière du bateau. Minecraft 26.3, Fabric et JEI
|
||||
restent ceux de beta.090 ; les textures beta.090 sont conservées.
|
||||
[Contrat et vérifications](boat-passengers-beta091.md). Aucune publication du canal
|
||||
ou installation personnelle n’est effectuée.
|
||||
|
||||
## beta.090 — Minecraft 26.3 finale
|
||||
|
||||
La cible locale passe à Minecraft 26.3, Fabric API 0.160.5+26.3, avec Loader
|
||||
0.19.5 et Java 25. Demeure et JEI sont reconstruits pour la même version ;
|
||||
le pack graphique devient beta.090. [Contrat et vérifications](minecraft-26-3-beta090.md).
|
||||
Les archives normal/Test beta.090 sont des livraisons locales : le canal
|
||||
publié et l'instance Prism ne sont pas modifiés par cette migration du projet.
|
||||
|
||||
## beta.077 — tourbillon et navigation
|
||||
|
||||
[Nuages](cloud-vortex-beta077.md) · [Menus](menu-navigation-beta076.md).
|
||||
Client natif, `check build`, sources et archives normal/Test vérifiés.
|
||||
Textures beta.070 et 155 anciennes archives conservées. Le lot de menus
|
||||
beta.076 est inclus ici ; aucun pack intermédiaire beta.076 n’a été publié.
|
||||
Aucun déploiement dans une instance personnelle ni sur le canal distant.
|
||||
|
||||
- [Sanctuary-beta.077.mrpack](../build/Sanctuary-beta.077.mrpack), 9608669 octets.
|
||||
SHA-256 : `1c3839f086e9545c920e4ebfc13f99a25d0684fa6f2dc8e1b2a842a8e7044045`.
|
||||
- [Sanctuary-Test-beta.077.mrpack](../build/Sanctuary-Test-beta.077.mrpack), 9627602 octets.
|
||||
SHA-256 : `1b0c302b9d4d5f59d5e954adbecde4acbacd9409c8cd6a743ccbe116826d7c0a`.
|
||||
|
||||
## beta.075 — bibliothèque locale
|
||||
|
||||
[Correctif et vérifications](plans-library-beta075.md). Retrait du bouton
|
||||
Minecraft Schematics. Build, sources, JAR et exports normal/Test vérifiés ;
|
||||
onze archives précédentes conservées. Aucun déploiement personnel ou distant.
|
||||
|
||||
- [Sanctuary-beta.075.mrpack](../build/Sanctuary-beta.075.mrpack), 9594917 octets.
|
||||
SHA-256 : `fba6e648c2569b115713060862166b80ffc38620929f2fb3e110868d61d6257e`.
|
||||
- [Sanctuary-Test-beta.075.mrpack](../build/Sanctuary-Test-beta.075.mrpack), 9613850 octets.
|
||||
SHA-256 : `65a7f40f8c10c58437980cf6ea40e45b5b8c9e1e75e8dbadcc981aa5f41e19fd`.
|
||||
|
||||
## beta.074 — autonomie des familiers
|
||||
|
||||
[Contrat et vérifications](familiar-autonomy-beta074.md). Quatre comportements
|
||||
spontanés distincts, garde locale et ordres H bref/maintenu. Textures beta.070.
|
||||
Trois parcours client natifs et `check build assemblePack assembleTestPack`
|
||||
réussis. JAR, 1 689 classes et sources comparés ; neuf archives précédentes
|
||||
conservées. Aucun déploiement sur le canal ou dans une instance personnelle.
|
||||
|
||||
- [Sanctuary-beta.074.mrpack](../build/Sanctuary-beta.074.mrpack), 9595113 octets.
|
||||
SHA-256 : `cc73e93c2ae17d6b52b6c8dd53639771645c5e5becd848e2c76765e32c919c5d`.
|
||||
- [Sanctuary-Test-beta.074.mrpack](../build/Sanctuary-Test-beta.074.mrpack), 9614048 octets.
|
||||
SHA-256 : `0851e10350788b76efa96ec1a50db951a74200213399e2a4216f8d5b1b8fafcb`.
|
||||
|
||||
[Reçu de vérification](../build/autonomy074-artifact.json).
|
||||
|
||||
## beta.073 — arènes et paris
|
||||
|
||||
Livraison locale isolée sur Minecraft 26.3-pre-2. Le resource pack reste
|
||||
beta.070. [Contrat du ticket](arenas-beta073.md). Aucun canal distant ni aucune
|
||||
instance personnelle n'est modifié. Client natif, `check build`,
|
||||
assemblage et vérification des archives réussis.
|
||||
|
||||
- [Pack normal beta.073](../build/Sanctuary-beta.073.mrpack), 9 592 283 octets.
|
||||
SHA-256 : `9ef9c1c2f156d1eb9dcb31ae0f0364a798e46867ce86d56ae25fa2ae5c5105ca`.
|
||||
- [Monde plat rapide beta.073](../build/Sanctuary-Test-beta.073.mrpack), 9 611 218 octets.
|
||||
SHA-256 : `5394215474faea6a321cf44d64c01acaaa7fda554448110a3c8b47dcddf2f9c7`.
|
||||
- [Contrôles et provenance](../build/arena073-artifact.json).
|
||||
|
||||
|
||||
## beta.072 — statues et plans natifs
|
||||
|
||||
[Contrat, formats et essais](statues-plans-beta072.md). Outil K intégré à
|
||||
Sanctuary, création de statues à partir des modèles et textures du jeu,
|
||||
import/export de plans, aperçu et collage créatif contrôlé côté serveur.
|
||||
Sans dépendance Litematica/MaLiLib ; textures beta.070 conservées.
|
||||
|
||||
- [Pack normal beta.072](../build/Sanctuary-beta.072.mrpack), 9 534 082 octets.
|
||||
SHA-256 : `ccadfa614595f4409cb8eab9c795f112e65854c8e84864c8a8fb67dbc2de450e`.
|
||||
- [Monde plat rapide beta.072](../build/Sanctuary-Test-beta.072.mrpack), 9 553 013 octets.
|
||||
SHA-256 : `cb1786ffbf0290fc2cc5437647423e96abee8bca7737537aecbb12de98aee811`.
|
||||
|
||||
Reçu `build/statues-research/artifacts.json` : 1 671 classes, 758 sources Java,
|
||||
150 ressources graphiques conformes ; index et ZIP vérifiés. Client natif,
|
||||
sept tests serveur et 130 tâches Gradle réussis. Archives locales uniquement ;
|
||||
aucun canal public ni instance personnelle modifié.
|
||||
|
||||
## beta.071 — personnalités et montures
|
||||
|
||||
[Contrat, audit et tests](familiar-personality-beta071.md). Quatre caractères,
|
||||
poursuite plus vive, araignées grimpantes, Nautilus qui préserve l’air du
|
||||
cavalier et Strider à la surface de la lave. Construction depuis les sources
|
||||
isolées de la 71 pour préserver le chantier simultané de la 72.
|
||||
|
||||
- [Pack normal beta.071](../build/Sanctuary-beta.071.mrpack), 9462323 octets.
|
||||
SHA-256 : `1ab36663fe24313597c5328170a3eb2ca2e33bfdfc4c6fbc85c1f5c03102628c`.
|
||||
- [Monde plat rapide beta.071](../build/Sanctuary-Test-beta.071.mrpack), 9481258 octets.
|
||||
SHA-256 : `06309f4cd382053fb42d80c3f131152932e07523ace799c50d1d899026029a92`.
|
||||
|
||||
Reçu `build/familiar071-artifact.json` : 1 651 classes conformes, seules les
|
||||
classes du familier prévues par le ticket changent. Les 150 ressources de la
|
||||
beta.070, JEI, les autres ressources et les archives précédentes sont intacts.
|
||||
Aucun canal public ni instance personnelle modifié.
|
||||
|
||||
## beta.070 — resource pack embarqué
|
||||
|
||||
[Contrat et vérifications](resourcepack-beta070.md). La source versionnée du
|
||||
pack est embarquée dans le JAR et activée par défaut via Fabric ; aucun fichier
|
||||
d’options personnelles n’est distribué. Les variantes normal/Test et le ZIP
|
||||
autonome utilisent les mêmes 150 ressources, comparées octet pour octet.
|
||||
|
||||
- [Pack normal beta.070](../build/Sanctuary-beta.070.mrpack), 9451989 octets.
|
||||
SHA-256 : `9a582e17394bcb7327bd3b5a5a789b297431e41bf43409ed117fac728bbda46c`.
|
||||
- [Monde plat rapide beta.070](../build/Sanctuary-Test-beta.070.mrpack), 9470924 octets.
|
||||
SHA-256 : `5732e570c1af20f4d4896292c51bb38fb5c642d0ec81c6a1273ba27318938cd4`.
|
||||
- [Resource pack autonome beta.070](../build/Sanctuary-Resource-Pack-beta.070.zip), 3757596 octets.
|
||||
SHA-256 : `fe81653d09584f67da5f56c4fd6c866c733ec81e07559a5f132a44d44bbaadb6`.
|
||||
|
||||
Source du resource pack : commit `85e062ed91c7`. Reçu
|
||||
`build/resourcepack070-artifact.json`, 1 648 classes conformes et archives
|
||||
beta.069 intactes. Aucun canal public ni instance personnelle modifié.
|
||||
|
||||
## beta.069 — ordres du familier sur H
|
||||
|
||||
[Contrat et vérifications](familiar-orders-beta069.md). Retour des ordres
|
||||
sur H et du changement de main sur F ; G reste le pouvoir. Parcours client,
|
||||
compilation générale et archives vérifiés.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.069.mrpack), 5726225 octets.
|
||||
SHA-256 : `1c923452ff4d5d186309390fac3306b8e05162143c852619b7519741002aa165`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.069.mrpack), 5745158 octets.
|
||||
SHA-256 : `bed499fa29f4247a9e321207df503b3147b8b4fc8c8541d817cdfe2a2db9a945`.
|
||||
|
||||
Reçu `build/familiar069-artifact.json` : 1 647 classes conformes, seule
|
||||
`FamiliarClient` change ; anciens packs conservés. Aucun canal public ni
|
||||
instance personnelle modifié.
|
||||
|
||||
## beta.068 — animation du préchargement
|
||||
|
||||
[Contrat et vérifications](loading-animation-beta068.md). Petite ligne SGA
|
||||
animée pendant l’attente, étapes réelles et progression native conservées.
|
||||
Client natif, comparaison de huit captures et compilation générale réussis.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.068.mrpack), 5726390 octets.
|
||||
SHA-256 : `cfb55d414186e6be5f0e19770049158302d4fbf37c0fa696306acda428594a2e`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.068.mrpack), 5745324 octets.
|
||||
SHA-256 : `643913caf577ee61b23747f378e9a21f5b1a54531901791d47d8ad0a75531dff`.
|
||||
|
||||
Reçu `build/loading068-artifact.json` : 1 647 classes conformes ; archives
|
||||
beta.067, introduction, cache, textures et JEI préservés. Aucun canal public
|
||||
ni instance personnelle modifié.
|
||||
|
||||
## beta.067 — touche et vol du dragon
|
||||
|
||||
[Contrat et vérifications](familiar-controls-beta067.md). F ouvre les ordres,
|
||||
le dragon regarde devant lui, le grand porté monte avec la touche de saut.
|
||||
Client natif et compilation générale réussis.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.067.mrpack), 5724176 octets.
|
||||
SHA-256 : `a0dd2dc94aee0418b6ec8e29c24c847506627d63f6d22f1980ef7eacf38bc3fa`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.067.mrpack), 5743110 octets.
|
||||
SHA-256 : `e2605534bbe7eed0559304f7c2cb9bd6618178eb64b042e45ff2aa596f0bec22`.
|
||||
|
||||
Reçu `build/familiar067-artifact.json` : 1 646 classes compilées conformes ;
|
||||
archives beta.066, textures et JEI inchangés. Aucun déploiement personnel
|
||||
ni modification du canal public.
|
||||
|
||||
## beta.066 — cosmétiques animés sans doublon
|
||||
|
||||
[Contrat et vérifications](head-render-beta066.md). Le rendu sépare les parties
|
||||
fixes des blocs portés de leur animation native : plus de second coffre fermé
|
||||
ou de cloche immobile. Parcours client et compilation générale réussis.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.066.mrpack), 5721524 octets.
|
||||
SHA-256 : `04e584ba7047e87e66316ba6e06f9d809e2813a6f4227067f20ca2ace7239f3a`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.066.mrpack), 5740457 octets.
|
||||
SHA-256 : `de6563aa48dededb6c1afa967987bd25e5134644596ea1908b1fa1768463aae5`.
|
||||
|
||||
Reçu `build/cosmetic066-artifact.json`. Archives beta.065, textures et JEI
|
||||
préservés ; seule la source principale `HeadCosmeticModels` change.
|
||||
Aucun canal ni instance personnelle modifié.
|
||||
|
||||
## beta.065 — collisions des bateaux
|
||||
|
||||
[Contrat et vérifications](boat-collisions-beta065.md). Les coques complètes et
|
||||
les virages respectent les murs. 88 variantes et seize parcours pilotés en eau
|
||||
ou en vol vérifiés. Build et comparaison des archives réussis.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.065.mrpack), 5721084 octets.
|
||||
SHA-256 : `71ff1736817e2953f88a8afda5858b2e7ae23c360efdb7e25f149cbff049d764`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.065.mrpack), 5740018 octets.
|
||||
SHA-256 : `4c4931146a05d6f57e9abf2303b039ab7a7bc16471a0b864873b86bef297431d`.
|
||||
|
||||
Reçu `build/boat065-artifact.json`. Archives beta.064 intactes ; seul
|
||||
`CrewBoat` change dans le code principal. Aucun canal ni instance personnelle
|
||||
modifié.
|
||||
|
||||
## beta.064 — cache et préparation du monde
|
||||
|
||||
[Contrat et vérifications](loading-cache-beta064.md). Plans dérivés réutilisés
|
||||
à la réouverture, étapes réelles sur fond uni, portail de préparation supprimé.
|
||||
Introduction complète conservée. Build et parcours client natif réussis.
|
||||
|
||||
- [Pack normal](../build/Sanctuary-beta.064.mrpack), 5720330 octets.
|
||||
SHA-256 : `c05b78e2caf27d52cb318979ee66e19e5bca9c90673f8868ae50f85f0e2ff2c0`.
|
||||
- [Monde plat rapide](../build/Sanctuary-Test-beta.064.mrpack), 5739264 octets.
|
||||
SHA-256 : `962800291875ab5bebda1abaedc798e7cf110ba0ef13ac168a0b85b3b2c19d24`.
|
||||
|
||||
Reçu `build/loading064-artifact.json` : 1 645 classes conformes au build,
|
||||
archives beta.063 préservées. Aucun canal ni instance personnelle modifié.
|
||||
|
||||
## beta.061 — musique au portail et montures colossales
|
||||
|
||||
[Contrat et vérifications](arrival-mount-beta061.md). Musique démarrant au
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# beta.075 — bibliothèque de plans
|
||||
|
||||
Branche `codex/plans-library-beta075`.
|
||||
|
||||
Dans **K → Bibliothèque**, le bouton « Rechercher sur Minecraft Schematics »
|
||||
est retiré à la demande du créateur. Ses libellés FR/EN inutilisés sont supprimés.
|
||||
Le placement des autres widgets se réajuste avec la disposition native.
|
||||
|
||||
L’ouverture du dossier, l’actualisation, le glisser-déposer et l’import des
|
||||
plans locaux conservent leur fonctionnement. Aucun format, monde, texture ou
|
||||
identifiant de contenu ne change. Minecraft 26.3-pre-2, resource pack beta.070.
|
||||
|
||||
## Vérifications
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en 2 min 39 s, 124 tâches.
|
||||
Les 1 689 classes du JAR correspondent au build ; seul PlansScreen change
|
||||
par rapport à beta.074. Les archives normal/Test et les sources sont vérifiées,
|
||||
le lien est absent du bytecode et onze archives précédentes restent identiques.
|
||||
Reçu : `build/library075-artifact.json`. Aucun nouvel essai client graphique.
|
||||
Le serveur dédié reste
|
||||
exclu conformément au refus d’accepter son EULA (`-x :sanctuary:runGameTest`).
|
||||
Aucun déploiement dans une instance personnelle.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.075.mrpack](../build/Sanctuary-beta.075.mrpack), 9594917 octets.
|
||||
SHA-256 : `fba6e648c2569b115713060862166b80ffc38620929f2fb3e110868d61d6257e`.
|
||||
- [Sanctuary-Test-beta.075.mrpack](../build/Sanctuary-Test-beta.075.mrpack), 9613850 octets.
|
||||
SHA-256 : `65a7f40f8c10c58437980cf6ea40e45b5b8c9e1e75e8dbadcc981aa5f41e19fd`.
|
||||
@@ -306,6 +306,19 @@ jusqu'à ce ticket. Mini-carte, marqueurs, partage, recettes, plans et autres
|
||||
aptitudes gardent leurs tickets propres. Leur absence ne bloque pas le New
|
||||
Game+ lorsque les six compétences sont au maximum.
|
||||
|
||||
Le [cadrage CLAIM-01 — titres de propriété temporaires](property-titles-ticket.md)
|
||||
précise les décisions du 15 septembre 2026 : un titre couvre un seul chunk ;
|
||||
il faut renommer l'objet puis faire un clic droit pour revendiquer le chunk.
|
||||
Un autre titre portant le même nom permet d'étendre la même propriété,
|
||||
y compris à un chunk séparé, sans revendiquer les chunks intermédiaires.
|
||||
Les titres restent attachés aux chunks ; une réserve de **saphirs consommés
|
||||
successivement** entretient leur protection en temps réel, même lorsque le
|
||||
joueur est déconnecté, tant que le serveur tourne. À la fin de la période
|
||||
payée, sans assez de saphirs pour renouveler, la protection disparaît
|
||||
immédiatement. Acquisition des titres, tarifs d'entretien, paliers, durée des
|
||||
périodes, traitement des arrêts du serveur et droits de réservation sans
|
||||
protection restent à décider ; ce mécanisme n'est pas encore implémenté.
|
||||
|
||||
## Références et validation des livraisons
|
||||
|
||||
La référence historique est consultée en lecture seule dans `../26.2/sanctuary` :
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
# CLAIM-01 — Titres de propriété temporaires
|
||||
|
||||
**Ticket local — conception en cours, décisions du 15 septembre 2026.**
|
||||
Ce document prépare le résultat jouable ; la protection n'est pas implémentée.
|
||||
Branche réservée : `codex/property-titles`. Le checkout existant reste sur sa
|
||||
branche de travail pour préserver les travaux en cours. Aucun numéro de
|
||||
livraison réservé et aucune issue distante publiée.
|
||||
|
||||
## Intention et décisions confirmées
|
||||
|
||||
Le joueur achète des **titres de propriété temporaires** donnant des privilèges
|
||||
sur un terrain. Il choisit un niveau de protection et constitue une réserve
|
||||
de saphirs pour l'entretenir. Le titre reste attaché au chunk ; la protection
|
||||
accordée est temporaire et renouvelable.
|
||||
|
||||
**Un titre couvre un seul chunk**, soit une emprise horizontale de 16 × 16
|
||||
blocs alignée sur la grille Minecraft. Un même titre ne couvre pas plusieurs
|
||||
chunks à la fois. Son entretien utilise ensuite des saphirs.
|
||||
|
||||
**Le titre est un objet à renommer avant utilisation.** Le joueur fait un
|
||||
clic droit avec ce titre dans le chunk à revendiquer. Le nom donné au titre
|
||||
sert de nom à la propriété ; utiliser un autre titre portant le même nom
|
||||
dans un autre chunk étend cette propriété. Chaque chunk ajouté nécessite
|
||||
son propre titre, conformément à la règle « un titre = un chunk ».
|
||||
**Les chunks d'une même propriété peuvent être séparés** : aucune contiguïté
|
||||
n'est requise. Les chunks situés entre eux ne sont pas revendiqués par cette
|
||||
extension. Le moyen de renommer l'objet reste à préciser.
|
||||
|
||||
**Les saphirs sont consommés successivement pour entretenir le niveau de
|
||||
protection choisi. Les titres restent attachés aux chunks.** À niveau et
|
||||
emprise identiques, ajouter des saphirs prolonge l'entretien disponible.
|
||||
Cette décision remplace la consommation successive de titres envisagée au
|
||||
début de la discussion.
|
||||
|
||||
**L'entretien se fait en temps réel**, y compris lorsque le joueur est
|
||||
déconnecté, tant que le serveur tourne. Il ne dépend pas du temps de présence
|
||||
du titulaire. Le traitement du temps écoulé pendant un arrêt du serveur reste
|
||||
à décider séparément.
|
||||
|
||||
**La protection disparaît immédiatement à épuisement de la couverture** :
|
||||
lorsque la dernière période payée se termine et que la réserve ne contient
|
||||
pas assez de saphirs pour renouveler, aucun délai de grâce ni baisse
|
||||
progressive ne s'applique. Une réserve vide ne raccourcit pas la période
|
||||
déjà payée. Le titre reste attaché au chunk ; la possibilité pour un autre
|
||||
titulaire de revendiquer ce chunk sans protection reste à décider.
|
||||
|
||||
La protection envisagée rend les blocs plus longs à miner par les autres.
|
||||
Le créateur évoque un premier ralentissement doublé et une protection pouvant
|
||||
aller jusqu'à des blocs presque incassables, voire incassables. Les valeurs,
|
||||
les bénéficiaires et la limite exacte restent à décider.
|
||||
|
||||
## Modèle proposé à préciser
|
||||
|
||||
Séparer dans le fonctionnement et l'interface :
|
||||
|
||||
- **Niveau choisi** : résistance appliquée et coût d'entretien associé.
|
||||
- **Réserve** : saphirs disponibles pour les renouvellements successifs.
|
||||
- **Échéance en cours** : moment de la prochaine consommation ou fin de
|
||||
couverture, selon le contrat temporel à retenir.
|
||||
|
||||
Proposition : un niveau plus élevé coûte davantage de saphirs. Le coût et
|
||||
la durée d'une période payée ne sont pas fixés ; l'emprise est d'un chunk
|
||||
par titre. La gestion des réserves pour plusieurs chunks reste à préciser.
|
||||
La consommation en temps réel est confirmée ; une consommation
|
||||
supplémentaire provoquée par les attaques n'a pas été demandée.
|
||||
|
||||
Pour le premier ralentissement, l'interprétation proposée est un **temps de
|
||||
minage multiplié par deux** pour un joueur non autorisé, à bloc, outil et
|
||||
conditions identiques. Cela reste à confirmer. Les privilèges supplémentaires
|
||||
du titulaire ne sont pas encore définis.
|
||||
|
||||
## Économie : entretien en saphirs, acquisition à définir
|
||||
|
||||
Le **saphir est retenu pour entretenir la protection des titres déjà posés**.
|
||||
La [vision](vision.md#les-trois-gemmes) lui attribue déjà la réservation et la
|
||||
sauvegarde de quantités limitées d'objets dans le catalogue. Ce nouvel usage
|
||||
prolonge son rôle de conservation, sans supposer cette économie déjà disponible.
|
||||
|
||||
Restent à choisir : monnaie et prix d'achat initial des titres, lieu et geste
|
||||
d'achat, obtention effective des saphirs, tarifs d'entretien, partage et
|
||||
éventuel transfert. Le titre utilisable en jeu est un objet renommable ; le
|
||||
registre serveur et le dépôt des saphirs dans la réserve restent à définir.
|
||||
|
||||
## Arbitrages nécessaires au premier lot jouable
|
||||
|
||||
- Emprise d'un chunk par titre confirmée ; préciser la portée verticale,
|
||||
les dimensions concernées, le nombre maximal de chunks par titulaire et
|
||||
les règles de chevauchement. Choisir une réserve par chunk ou une réserve
|
||||
commune avec des règles explicites d'affectation des saphirs et de
|
||||
renouvellement lorsque le solde ne suffit pas pour tous les chunks.
|
||||
- Création et extension par titre renommé puis clic droit confirmées ;
|
||||
préciser le moyen de renommage, les noms admis, leur comparaison et les
|
||||
collisions entre titulaires. Les chunks séparés sont autorisés. Définir
|
||||
comment départager le chunk du joueur et celui du bloc visé à une frontière,
|
||||
et l'effet d'un clic dans un chunk déjà revendiqué.
|
||||
Le nom sert au regroupement ; le serveur doit aussi vérifier les droits
|
||||
d'extension pour qu'un nom identique ne permette pas de prendre le contrôle
|
||||
de la propriété d'un autre titulaire.
|
||||
- Titulaire : joueur, faction ou les deux ; droits des membres, invités et
|
||||
tiers, et rapport éventuel au prestige. Demeure mesure l'habitation et ne
|
||||
vaut pas attribution d'un titre.
|
||||
- Paliers de résistance, privilèges et incassabilité éventuelle ; articulation
|
||||
avec les outils, enchantements et aptitudes de minage existants.
|
||||
- Coût en saphirs et durée réelle de chaque période selon le niveau ;
|
||||
financement de la première activation ; traitement des chunks déchargés
|
||||
et du temps écoulé pendant les arrêts du serveur. La déconnexion du joueur
|
||||
ne suspend pas l'entretien.
|
||||
- Changement de niveau : prise d'effet, traitement de la période payée et du
|
||||
temps restant, pour éviter de gagner de la couverture par des changements
|
||||
répétés.
|
||||
- Avertissement avant épuisement, droits de réservation d'un titre sans
|
||||
protection et réactivation après réapprovisionnement. Le titre reste attaché
|
||||
au chunk et la protection disparaît immédiatement en fin de couverture.
|
||||
- Abandon, transfert, conflits de réservation et devenir du stock restant.
|
||||
- Portée de la protection face aux explosions, pistons, fluides, mobs,
|
||||
inventaires et actions groupées ; distinguer les droits d'interaction de la
|
||||
résistance au minage.
|
||||
|
||||
## Réception de la future implémentation
|
||||
|
||||
Le premier lot doit permettre d'obtenir des titres par la voie retenue,
|
||||
réserver un terrain, choisir sa protection, approvisionner la réserve en
|
||||
saphirs et observer leur consommation successive ainsi que l'effet sur le
|
||||
minage, avec conservation du titre attaché au chunk.
|
||||
|
||||
- Renommer un titre « Verger » et faire un clic droit dans un chunk libre
|
||||
crée la propriété « Verger ». Utiliser un autre titre de même nom dans un
|
||||
second chunk admissible étend la même propriété à ce chunk. Une autre
|
||||
propriété, nommée différemment, conserve son emprise.
|
||||
- Répéter l'extension dans un chunk séparé du premier par des chunks libres :
|
||||
les deux chunks appartiennent à la même propriété, sans revendiquer ni
|
||||
protéger les chunks intermédiaires.
|
||||
- Un titre non renommé ne revendique aucun chunk et explique le renommage
|
||||
nécessaire. Un refus d'extension ou un conflit ne dépense pas de titre et
|
||||
ne modifie pas de terrain ; vérifier les collisions de noms entre joueurs.
|
||||
- Deux joueurs vérifient les droits et le ralentissement de chaque palier,
|
||||
à conditions identiques, ainsi que les limites du terrain.
|
||||
- Un titre couvre exactement le chunk désigné : sa protection ne déborde
|
||||
pas sur le chunk voisin. Couvrir deux chunks nécessite des titres distincts ;
|
||||
renouveler le même chunk ne modifie pas son emprise.
|
||||
- Ajouter des saphirs à niveau et emprise constants prolonge l'entretien sans
|
||||
modifier la résistance choisie. Un renouvellement conserve la couverture
|
||||
et le titre attaché, sans exiger un nouveau titre pour le même chunk.
|
||||
- Déconnecter le titulaire en laissant le serveur tourner : à son retour,
|
||||
la réserve et la couverture reflètent le temps réel écoulé, y compris si
|
||||
plusieurs renouvellements en saphirs ont eu lieu pendant son absence.
|
||||
- Épuisement, réapprovisionnement et changement de niveau suivent les règles
|
||||
arrêtées, avec un état et une échéance compréhensibles en FR/EN.
|
||||
- Avec une réserve vide ou insuffisante pour renouveler, vérifier la
|
||||
protection jusqu'à la fin de la période payée, puis sa disparition immédiate
|
||||
à l'échéance, y compris lorsque le titulaire est déconnecté. Le titre reste
|
||||
attaché ; le minage retrouve les règles ordinaires applicables, sans
|
||||
résistance résiduelle provenant des titres.
|
||||
- Achat, consommation et droits font autorité côté serveur. Des requêtes
|
||||
répétées ou simultanées et un redémarrage ne dupliquent ni dépense, ni titre,
|
||||
ni saphir, et ne remettent pas gratuitement la durée à zéro.
|
||||
- Un contrat de sauvegarde et de migration explicite précède toute donnée
|
||||
persistante. Le chargement d'une ancienne partie n'attribue aucun terrain
|
||||
implicitement ; aucune régénération de chunks n'est nécessaire.
|
||||
- Tester les interactions retenues ci-dessus et les actions groupées, puis
|
||||
lancer `./gradlew check build`. Une livraison de distribution exige aussi
|
||||
`./gradlew assemblePack` et le [versionnement](versioning.md) mod/pack.
|
||||
|
||||
## État actuel
|
||||
|
||||
L'emprise est fixée à un chunk par titre. Le titre est renommé puis utilisé
|
||||
par clic droit ; un même nom permet d'étendre la propriété à un autre chunk.
|
||||
Les chunks d'une même propriété peuvent être séparés.
|
||||
Les titres restent attachés aux chunks. La consommation successive de saphirs
|
||||
en temps réel pour maintenir un niveau choisi, y compris lorsque le joueur est
|
||||
déconnecté, est confirmée.
|
||||
La protection disparaît immédiatement lorsque la couverture est épuisée.
|
||||
Les autres arbitrages sont explicitement ouverts ou proposés ci-dessus.
|
||||
Ce cadrage est documentaire : aucun code, binaire, monde ou format de
|
||||
sauvegarde modifié ; aucun test de gameplay exécuté pour ce ticket.
|
||||
@@ -0,0 +1,90 @@
|
||||
# beta.070 — resource pack versionné et actif par défaut
|
||||
|
||||
Branche `codex/resourcepack-beta070`.
|
||||
|
||||
## Source et version
|
||||
|
||||
La source unique est `ressources-pack/sanctuary/`. Le dossier fourni
|
||||
`Sanctuary-Resource-Pack-base-26-3` contient 107 fichiers, dont 85 PNG.
|
||||
Tous ses assets sont repris sans retouche. Sept images diffèrent de la base :
|
||||
les six états `hud/food_*` et l’atlas `sanctuary/textures/gui/food_details.png`.
|
||||
Les 47 cœurs vanilla déjà présents dans la source restent identiques.
|
||||
Aucun remplacement des bulles de respiration.
|
||||
|
||||
`ressources-pack/sanctuary/releases/beta.070.json` fixe les empreintes des
|
||||
150 fichiers distribués, la provenance des 107 fichiers fournis et le format
|
||||
exact **97.1** de Minecraft **26.3-pre-2**. Les guides ont été actualisés ; le
|
||||
manifeste Minecraft porte le numéro beta.070 et une description FR/EN.
|
||||
|
||||
Le numéro graphique `resource_pack_version` est distinct des versions du mod
|
||||
et du modpack. Un correctif de code ultérieur peut garder ces mêmes textures.
|
||||
Une retouche graphique demande un nouveau manifeste de release, en conservant
|
||||
celui des versions précédentes. `verifyResourcePack` détecte toute dérive des
|
||||
fichiers, des empreintes, des CRC PNG, des JSON ou du format.
|
||||
|
||||
## Chargement par défaut
|
||||
|
||||
Gradle copie directement cette source dans le mod à
|
||||
`resourcepacks/textures/`. L’API Fabric 0.160.0+26.3 enregistre le pack natif
|
||||
`sanctuary:textures` avec `DEFAULT_ENABLED`. Il est donc actif dès sa première
|
||||
apparition, y compris dans une instance existante qui découvre ce pack.
|
||||
Le joueur garde la possibilité de le désactiver ou de placer un autre pack
|
||||
au-dessus ; son choix n’est pas réinitialisé à chaque lancement.
|
||||
|
||||
Aucun `options.txt` livré, ni écrasement des réglages personnels. La version
|
||||
normal et la version Test embarquent le même resource pack dans le même mod.
|
||||
Le ZIP `Sanctuary-Resource-Pack-beta.070.zip` est également exporté pour un usage
|
||||
séparé ; il n’est pas nécessaire de l’ajouter une seconde fois dans Sanctuary.
|
||||
Il conserve les namespaces natifs : la jauge dynamique, les aperçus alimentaires
|
||||
et les infobulles utilisent leurs chemins de textures existants.
|
||||
|
||||
## Vérifications natives
|
||||
|
||||
`ResourcePack070ClientChecks` réussit en **46 s** : activation au démarrage
|
||||
sans modifier la sélection, format reconnu compatible, priorité effective et
|
||||
égalité des octets chargés pour les sept PNG modifiés, respiration native,
|
||||
désactivation conservée après redécouverte des packs, réactivation.
|
||||
|
||||
Captures inspectées : le pack est dans la colonne « Selected », la description
|
||||
porte beta.070, les sprites de faim et de saturation proviennent des nouveaux
|
||||
dessins dans l’atlas natif. Preuves : `build/resourcepack070-client.log` et
|
||||
`build/resourcepack070-evidence/`. Pas de nouveau monde ni de serveur dans ce
|
||||
test ; les formules alimentaires ne sont pas modifiées.
|
||||
|
||||
```sh
|
||||
JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
|
||||
./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryResourcePack070ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
./gradlew verifyResourcePack assembleResourcePack
|
||||
```
|
||||
|
||||
## Livraison vérifiée
|
||||
|
||||
Source du resource pack enregistrée dans le commit `85e062ed91c74fcc3695e1e224fe51ac8fd010e0`.
|
||||
Les **150 fichiers distribués** ont été relus dans l’objet Git et leurs
|
||||
empreintes correspondent au manifeste. Ce commit ne contient que la source
|
||||
du resource pack ; les chantiers de code préexistants restent dans l’arbre de
|
||||
travail. Aucun push ni tag de l’ensemble des mods n’a été créé.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en **2 min 28 s**, 124 tâches,
|
||||
avec les profils client/test rapide et `-x :sanctuary:runGameTest`. Le serveur
|
||||
dédié reste exclu conformément au choix de ne pas accepter son EULA.
|
||||
|
||||
Les deux MRpacks contiennent les mêmes textures que le ZIP et que la source.
|
||||
**1 648 classes** conformes à la compilation, seuls `SanctuaryKnowledgeClient`
|
||||
et `SanctuaryResourcePack` changent par rapport à beta.069. Les autres ressources
|
||||
existantes et JEI restent identiques ; deux libellés FR/EN et le pack embarqué
|
||||
sont ajoutés. Les archives beta.069 conservent leurs empreintes.
|
||||
|
||||
Reçu : `build/resourcepack070-artifact.json`.
|
||||
|
||||
|
||||
- [Pack normal beta.070](../build/Sanctuary-beta.070.mrpack), 9451989 octets.
|
||||
SHA-256 : `9a582e17394bcb7327bd3b5a5a789b297431e41bf43409ed117fac728bbda46c`.
|
||||
- [Monde plat rapide beta.070](../build/Sanctuary-Test-beta.070.mrpack), 9470924 octets.
|
||||
SHA-256 : `5732e570c1af20f4d4896292c51bb38fb5c642d0ec81c6a1273ba27318938cd4`.
|
||||
- [Resource pack autonome beta.070](../build/Sanctuary-Resource-Pack-beta.070.zip), 3757596 octets.
|
||||
SHA-256 : `fe81653d09584f67da5f56c4fd6c866c733ec81e07559a5f132a44d44bbaadb6`.
|
||||
|
||||
Aucun déploiement personnel, aucune publication du canal, aucun monde modifié.
|
||||
@@ -0,0 +1,50 @@
|
||||
# RP-HUD-01 — base de textures de vie et de faim
|
||||
|
||||
Ticket du 15 septembre 2026, branche `codex/resourcepack-hud-base`.
|
||||
Demande du créateur : préparer les textures Minecraft d'origine pour qu'il
|
||||
dessine ensuite lui-même la vie, la faim et les interfaces Sanctuary.
|
||||
|
||||
## Résultat
|
||||
|
||||
- 53 PNG ajoutés au resource pack existant : les 47 sprites de `hud/heart/`
|
||||
et les six sprites `hud/food_*`, extraits sans retouche du client 26.3-pre-2.
|
||||
- Manifeste corrigé du format provisoire `0` au format exact **97.1**,
|
||||
avec `min_format` et `max_format`.
|
||||
- [Guide de retouche FR/EN](../ressources-pack/sanctuary/HUD.md), correspondance
|
||||
des variantes et recette d'export ZIP ; empreintes d'origine dans
|
||||
[HUD-SOURCES.json](../ressources-pack/sanctuary/HUD-SOURCES.json).
|
||||
- Menus, panorama, progression, aptitudes et atlas alimentaire existants
|
||||
conservés. La respiration utilise toujours les ressources vanilla.
|
||||
|
||||
Le pack est une base graphique séparée du mod. Aucun code Java, identifiant,
|
||||
format de sauvegarde ni manifeste packwiz ne change dans ce ticket ; aucun
|
||||
nouveau binaire du mod n'est livré, donc aucun compteur beta n'est consommé.
|
||||
Les modifications beta.062/beta.063 déjà présentes restent hors de ce lot.
|
||||
|
||||
## Vérification
|
||||
|
||||
Contrôles effectués sur la base et son export local :
|
||||
|
||||
- Les 53 sprites correspondent octet pour octet au client officiel ; tous
|
||||
mesurent 9 × 9, conservent la transparence et passent le contrôle des CRC
|
||||
PNG et la décompression des données d'image.
|
||||
- Les 19 fichiers JSON et métadonnées se lisent correctement. Le format 97.1
|
||||
correspond au `version.json` du client ; les champs du manifeste suivent
|
||||
son lecteur `PackFormat`.
|
||||
- 121 fichiers préexistants sont inchangés, dont toutes les textures déjà
|
||||
présentes dans le resource pack et les travaux hors périmètre. Les seuls
|
||||
fichiers de ce relevé modifiés sont le manifeste et les guides ciblés.
|
||||
- Le ZIP contient 154 fichiers, avec `pack.mcmeta`, `pack.png` et `assets/`
|
||||
à la racine. Son intégrité et l'égalité de chaque entrée avec sa source
|
||||
sont vérifiées ; aucun fichier Finder `.DS_Store` n'est exporté.
|
||||
|
||||
Export local :
|
||||
[`Sanctuary-Resource-Pack-base-26.3-pre-2.zip`](../ressources-pack/Sanctuary-Resource-Pack-base-26.3-pre-2.zip),
|
||||
3 761 553 octets. SHA-256 :
|
||||
`21b2ce42e9c381191508c93929d5ce02ee70beeeb519cf58a9ae6b3acd35f107`.
|
||||
Reçu local ignoré : `build/resourcepack-hud-base/verification.json`.
|
||||
|
||||
Aucun essai de rendu en jeu ni installation personnelle effectué. Les
|
||||
commandes Gradle ne sont pas lancées pour ce lot de PNG et de documentation :
|
||||
le code et la distribution packwiz sont inchangés. Le contrôle visuel après
|
||||
les futures retouches du créateur est décrit dans le guide HUD.
|
||||
@@ -0,0 +1,192 @@
|
||||
# PLAN-01 — statues et plans légers — beta.072
|
||||
|
||||
Branche `codex/statues-plans-beta072`. Ticket ouvert le 15 septembre 2026.
|
||||
**Implémenté, essais natifs réussis et archives locales beta.072 vérifiées.**
|
||||
|
||||
## Demande et choix retenu
|
||||
|
||||
Extraire les modèles et textures réellement utilisés par Minecraft pour créer
|
||||
des statues en blocs, avec une palette de matériaux choisie par couleur.
|
||||
Le créateur demande un outil Sanctuary léger qui couvre l'essentiel des plans
|
||||
partagés en ligne. Il a retenu une implémentation native compatible avec les
|
||||
fichiers Litematica, sans embarquer Litematica ou MaLiLib.
|
||||
|
||||
Parcours : modèle → hauteur et palette → plan → aperçu positionnable et
|
||||
orientable → placement créatif, ou construction manuelle guidée en survie.
|
||||
Les plans importés partagent ce dernier parcours. Une bibliothèque locale,
|
||||
l'export `.litematic`, les couches et le décompte des blocs complètent l'outil.
|
||||
Le lien de recherche Minecraft Schematics livré en beta.072 est retiré en
|
||||
[beta.075](plans-library-beta075.md). La bibliothèque utilise les fichiers locaux.
|
||||
|
||||
## Utilisation
|
||||
|
||||
1. Appuyer sur **K** (raccourci modifiable dans les contrôles).
|
||||
2. Dans **Statue**, choisir une espèce, ou le mob visé au moment d'ouvrir
|
||||
l'écran. Régler la hauteur de 4 à 96 blocs et la palette : mélange, béton
|
||||
ou laine. La géométrie et les textures viennent du rendu natif et des
|
||||
ressources actives ; les pixels transparents ne deviennent pas des blocs.
|
||||
3. Dans **Bibliothèque**, charger un fichier local ou le déposer sur l'écran.
|
||||
Les dossiers `schematics/` et `schematics/sanctuary/` sont consultés.
|
||||
**Ouvrir le dossier** permet d’y déposer des plans ; **Actualiser** relit
|
||||
les fichiers disponibles.
|
||||
4. Dans **Construction**, ancrer le plan au point visé, régler ses coordonnées,
|
||||
tourner de 90°, isoler une couche et consulter les blocs restants.
|
||||
Les blocs corrects disparaissent de l'aperçu ; les conflits sont rouges.
|
||||
5. En créatif, **Placer** puis confirmer dans le jeu. En survie, poser les
|
||||
blocs normalement avec son inventaire ; le compteur suit l'avancement.
|
||||
**Exporter** écrit un `.litematic` dans `schematics/sanctuary/`, sans écraser
|
||||
les exports précédents.
|
||||
|
||||
L'aperçu est local et se ferme au changement de dimension ou à la déconnexion.
|
||||
Exporter avant de quitter conserve le plan. Le serveur Sanctuary est requis
|
||||
pour le collage créatif ; un aperçu seul ne donne aucun droit de placement.
|
||||
|
||||
## Compatibilité implémentée
|
||||
|
||||
- Minecraft **26.3-pre-2**, Java 25, versions Fabric du dépôt.
|
||||
- `.litematic` versions 4 à 7 en lecture, version 6 en écriture ; Sponge
|
||||
`.schem` v2/v3 en lecture ; structures vanilla `.nbt` en lecture. Fichiers
|
||||
NBT compressés gzip. Les palettes classiques `Name`/`Properties` et les clés
|
||||
natives 26.3 `id`/`properties` sont lues ; l'export Litematic conserve le
|
||||
contrat classique, indépendant de la version Minecraft.
|
||||
- Refus explicite des blocs ou propriétés inconnus, des formats non pris en
|
||||
charge et des données d'une version Minecraft plus récente. Aucun remplacement
|
||||
silencieux par de l'air ; aucune migration automatique d'anciens identifiants.
|
||||
- Les anciennes `.schematic` à identifiants numériques nécessitent une
|
||||
conversion externe. Ni archive de monde ni ZIP n'est un plan importable.
|
||||
- Import des blocs uniquement : les inventaires, commandes, entités vivantes,
|
||||
ticks différés et biomes d'un fichier tiers ne sont pas exécutés/importés.
|
||||
|
||||
## Contrat de monde et de sauvegarde
|
||||
|
||||
Les plans sont des fichiers clients indépendants ; aucun format de sauvegarde
|
||||
Sanctuary ni aucune génération n'évolue. Aucun monde personnel n'est ouvert
|
||||
par le développement. La conversion utilise un modèle de rendu, sans faire
|
||||
apparaître ni supprimer un mob. Un aperçu ne modifie pas le monde.
|
||||
|
||||
Le collage créatif demande une action explicite en jeu. Le serveur vérifie le
|
||||
mode réel, la taille, la portée, les chunks déjà chargés, la frontière du monde,
|
||||
les permissions et l'absence de blocs occupés. Un opérateur en survie reste en
|
||||
survie. Les blocs d'air du plan ne servent jamais à effacer le terrain.
|
||||
En survie, les poses et la consommation passent par Minecraft normalement.
|
||||
|
||||
## Limites de cette livraison
|
||||
|
||||
- Les statues sont des enveloppes creuses. Les couleurs sont approchées par
|
||||
celles des textures moyennes des matériaux ; la forme dépend de la hauteur
|
||||
choisie. Les effets, étiquettes, laisses et couches d'objets/blocs ne font pas
|
||||
partie de la capture. Les textures dynamiques absentes des ressources et les
|
||||
UV d'atlas spéciaux demandent encore un adaptateur.
|
||||
- L'aperçu utilise des faces colorées et les formes de sélection natives,
|
||||
sans reproduire toutes les textures et l'éclairage d'un bloc posé. Il dessine
|
||||
à 96 blocs du joueur et recalcule les blocs restants toutes les dix ticks.
|
||||
Le traitement des fichiers et la conversion géométrique passent par un
|
||||
unique fil de travail ; masquer le plan arrête son actualisation périodique.
|
||||
- Plafonds : 256 blocs par axe, 32 768 blocs non vides, 2 097 152 cellules de
|
||||
volume ; fichier compressé de 8 Mio et lecture NBT de 32 Mio au maximum.
|
||||
La capture refuse plus de 16 384 faces et la conversion plus de 8 millions
|
||||
d'échantillons. Un gros build communautaire peut dépasser ces limites.
|
||||
- Collage à moins de 192 blocs, dans des chunks chargés. Pas d'effacement,
|
||||
de remplacement du terrain occupé, de blocs administratifs ou sans objet
|
||||
associé. Le serveur consulte les permissions et le veto Fabric d'utilisation
|
||||
des blocs. La physique et les mises à jour des voisins reprennent ensuite.
|
||||
- Les matériaux comptent des états de blocs. Portes, lits et dalles doubles
|
||||
peuvent donc demander un nombre d'objets différent du nombre affiché.
|
||||
- Aucun import d'inventaire, de NBT de bloc ou d'entité ; aucun miroir, collage
|
||||
avec remplacement, remplissage automatique en survie ou catalogue web intégré.
|
||||
- Aucun benchmark comparatif avec Litematica n'est revendiqué. La réduction
|
||||
de périmètre et l'absence de dépendance supplémentaire sont vérifiables ;
|
||||
elles ne constituent pas une mesure de gain de FPS.
|
||||
|
||||
## Sources de compatibilité
|
||||
|
||||
Vérifiées le 15 septembre 2026 :
|
||||
|
||||
- [Litematica](https://modrinth.com/mod/litematica/versions) publie des versions
|
||||
26.2, sans release annoncée pour la cible exacte du dépôt.
|
||||
- [Source 26.3](https://github.com/sakura-ryoko/litematica/tree/101ac3a23649f916cdcf05f30a5036f72706a096)
|
||||
: cible 26.3-rc-1, rendu encore en chantier. Consultée pour le contrat du
|
||||
format ; aucun JAR tiers supposé compatible n'est ajouté au pack.
|
||||
- [Spécification Sponge v3](https://github.com/SpongePowered/Schematic-Specification/blob/master/versions/schematic-3.md).
|
||||
- [Recherche Minecraft Schematics](https://www.minecraft-schematics.com/search/).
|
||||
- [Litemapy](https://github.com/SmylerMC/litemapy), utilisé seulement pour écrire
|
||||
des fixtures synthétiques indépendantes et relire l'export, hors distribution.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Essais sur macOS, Java 25, Minecraft 26.3-pre-2 et Fabric API 0.160.0+26.3.
|
||||
Tous les mondes utilisés sont des mondes de développement jetables.
|
||||
|
||||
- **Client natif réussi** : les 88 espèces à œuf d'apparition ont fourni leur
|
||||
géométrie texturée. Un creeper a parcouru les vrais widgets de création,
|
||||
l'aperçu, les quatre rotations, les matériaux, l'export, la confirmation et
|
||||
le collage réseau. Le serveur et le client retrouvent les mêmes blocs.
|
||||
Résultat : **10 × 32 × 15**, **1 542 blocs**, 22 entrées de palette avec l'air.
|
||||
Seul ce modèle a fait l'objet du parcours complet de statue en jeu ; la
|
||||
capture des 88 espèces ne vaut pas inspection visuelle de 88 statues.
|
||||
- **Survie vérifiée** : un paquet de collage envoyé malgré le mode survie est
|
||||
refusé ; l'interface ne propose pas le collage. Une pose au clic droit natif
|
||||
consomme un objet et fait avancer le compteur. Interfaces FR/EN capturées ;
|
||||
les 95 nouvelles clés de traduction sont présentes dans les deux langues.
|
||||
- **Interopérabilité indépendante** : Litemapy 0.11.0b0 relit le fichier produit
|
||||
en jeu et retrouve dimensions, états et total de 1 542 blocs. Ses trois
|
||||
écrivains ont aussi produit les fixtures `.litematic`, Sponge et vanilla
|
||||
du test serveur. La dépendance Python reste dans un environnement ignoré ;
|
||||
seuls les petits exemples synthétiques en base64 sont versionnés.
|
||||
- **Serveur et formats réussis** : les six GameTests du ticket et le test de
|
||||
contrôle Fabric passent. Ils couvrent l'autorité créatif/survie, le refus
|
||||
complet sur bloc occupé ou permission refusée, les blocs administratifs,
|
||||
la portée, les régions négatives, les palettes traversant les mots de 64 bits,
|
||||
les fichiers indépendants, les entrées invalides, la transparence, les UV et
|
||||
les rotations.
|
||||
- **Build et distribution réussis** : `check build assemblePack assembleTestPack`
|
||||
termine en 3 min 8 s, 130 tâches. Les GameTests sont ciblés sur PLAN-01 dans
|
||||
le harnais plat ; les contrôles Java/Python généraux restent exécutés. Ce
|
||||
ciblage ne revendique pas une nouvelle validation de toute la génération.
|
||||
Un premier lancement avait échoué au démarrage Java du test historique
|
||||
`lostCityPlanner15Smoke` avec un message JavaFX ; le même test isolé puis
|
||||
l'ensemble de la commande réussissent sans modification de ce code.
|
||||
|
||||
Commande du parcours client :
|
||||
|
||||
```sh
|
||||
./gradlew :sanctuary:runClientGameTest \
|
||||
-PsanctuaryClientTests=true -PsanctuaryPlans072ClientTests=true \
|
||||
-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
|
||||
```
|
||||
|
||||
Commande de contrôle et d'assemblage finale :
|
||||
|
||||
```sh
|
||||
./gradlew check build assemblePack assembleTestPack \
|
||||
-PsanctuaryFocusedTests=plans072 -PsanctuaryAtlasOnly=true \
|
||||
-PsanctuaryClientTests=true -PsanctuaryPlans072ClientTests=true \
|
||||
-PsanctuaryQuickTests=true
|
||||
```
|
||||
|
||||
Puis `packwiz modrinth export --output ../Sanctuary-beta.072.mrpack` dans
|
||||
`build/packwiz/`, et l'équivalent `Sanctuary-Test-beta.072.mrpack` depuis
|
||||
`build/packwiz-test/`.
|
||||
|
||||
Les captures et reçus locaux sont conservés dans
|
||||
`build/statues-research/evidence/`, `client-tests.log` et `interoperability.json`
|
||||
du même dossier de recherche. Ils ne sont pas ajoutés au pack.
|
||||
|
||||
## Archives locales
|
||||
|
||||
Le mod et les manifestes passent à **beta.072** ; les textures restent en
|
||||
**beta.070**. Les 1 671 classes du JAR correspondent exactement aux classes
|
||||
compilées, les 758 sources Java à l'archive des sources, et les 150 ressources
|
||||
graphiques aux fichiers versionnés. Les deux MRpacks contiennent le même JAR
|
||||
Sanctuary ; seul le profil Test ajoute le module de monde plat. Versions,
|
||||
index packwiz, empreintes et intégrité ZIP sont vérifiés.
|
||||
|
||||
| Artefact | Octets | SHA-256 |
|
||||
| --- | ---: | --- |
|
||||
| [Pack normal](../build/Sanctuary-beta.072.mrpack) | 9 534 082 | `ccadfa614595f4409cb8eab9c795f112e65854c8e84864c8a8fb67dbc2de450e` |
|
||||
| [Monde plat rapide](../build/Sanctuary-Test-beta.072.mrpack) | 9 553 013 | `cb1786ffbf0290fc2cc5437647423e96abee8bca7737537aecbb12de98aee811` |
|
||||
| [Mod Sanctuary](../mods/sanctuary/build/libs/sanctuary-beta.072.jar) | 10 043 650 | `f324eba7046563e06671c27551497ad6254cac80a27b5adbf3887b20998f0325` |
|
||||
|
||||
Reçu : `build/statues-research/artifacts.json`. Les changements déjà présents
|
||||
des beta.062 à beta.071 sont conservés. Aucun canal public, instance Prism ou
|
||||
serveur personnel n'est synchronisé par cette préparation locale.
|
||||
@@ -0,0 +1,60 @@
|
||||
# beta.089 — Crash au contact du super piston
|
||||
|
||||
Branche : `codex/super-piston-collision-beta089`.
|
||||
Signalement : crash beta.088 sous Minecraft 26.3-pre-2, `Ticking entity`,
|
||||
pendant `LocalPlayer.moveTowardsClosestSpace` → `isSuffocating`.
|
||||
|
||||
## Cause et correction
|
||||
|
||||
Les propriétés de la tête et de la tige étaient copiées depuis le socle du
|
||||
piston natif. Son prédicat de suffocation lit `PistonBaseBlock.EXTENDED`.
|
||||
Cette propriété existe sur les socles, mais pas sur les pièces techniques :
|
||||
la recherche d'un espace libre autour du joueur levait une exception lorsque
|
||||
sa boîte de collision rencontrait `sanctuary:super_piston_head`.
|
||||
La tige héritait du même défaut. Le prédicat de visibilité copié capture
|
||||
aussi les propriétés du socle d’origine et relit ce même état : changer
|
||||
uniquement la suffocation ne suffisait pas.
|
||||
|
||||
La tête et la tige utilisent des propriétés neuves, avec des prédicats
|
||||
explicites de suffocation et d’occultation désactivés. Elles conservent leurs collisions physiques de plaque et de tige,
|
||||
leur résistance et leurs règles de mouvement. Les socles gardent le prédicat
|
||||
natif, avec suffocation seulement lorsqu'ils sont rétractés.
|
||||
|
||||
Aucun changement d'identifiant, d'état de bloc, de schéma ou de sauvegarde.
|
||||
Les pistons déjà assemblés restent compatibles : aucune reconstruction,
|
||||
conversion ou suppression de blocs n'est nécessaire. Les textures et le
|
||||
correctif de navigation du Fût beta.088 sont conservés.
|
||||
|
||||
## Validation ciblée
|
||||
|
||||
Le parcours client natif des super pistons est étendu pour contrôler tous
|
||||
les états des deux socles, de la tête et de la tige, côté client et serveur :
|
||||
suffocation, visibilité, support d'apparition et conduction redstone.
|
||||
Le chemin natif `collidesWithSuffocatingBlock` est aussi exercé avec le joueur
|
||||
sur les neuf cases de tête et les deux positions de tige de chaque variante,
|
||||
dans chacune des six orientations.
|
||||
|
||||
Le défaut initial a été reproduit avec la même `IllegalArgumentException`
|
||||
que dans le rapport : `build/piston089-before-client.log`. Le contrôle de
|
||||
visibilité a ensuite révélé la capture des anciennes propriétés, corrigée
|
||||
par les propriétés neuves décrites ci-dessus.
|
||||
|
||||
Le parcours complet passe en 1 min 25 s (`build/piston089-client.log`) :
|
||||
864 états contrôlés côté client et serveur ; contact natif du joueur avec
|
||||
les pièces ; deux variantes et six directions ; charge de 108 et refus de
|
||||
109 blocs ; obstacles, inventaires, slime/miel, transport vertical d'une
|
||||
entité, interruption, sérialisation, retour dans les chunks et démontage.
|
||||
Les essais se déroulent dans un monde de développement neuf, graine 87.
|
||||
|
||||
`check build assemblePack assembleTestPack` réussit en 2 min 35 s
|
||||
(124 tâches, 104 exécutées), avec `:sanctuary:runGameTest` explicitement exclu.
|
||||
Journal : `build/piston089-check.log`. Le reçu `build/piston089-artifact.json`
|
||||
vérifie les sources, le JAR, les archives et l'identité de tous les assets
|
||||
avec beta.088. Les seules classes compilées modifiées sont `SuperPistons`
|
||||
et ses classes internes (décalages de lignes de debug pour ces dernières).
|
||||
|
||||
Archives locales : `build/Sanctuary-beta.089.mrpack` et
|
||||
`build/Sanctuary-Test-beta.089.mrpack`. Les archives beta.088 sont intactes.
|
||||
Aucun déploiement sur Prism ou sur le canal publié, aucun serveur dédié
|
||||
lancé, aucune EULA acceptée. Validation native sur macOS ; pas d'exécution
|
||||
sur le poste Windows du signalement ni d'essai LAN à deux clients distincts.
|
||||
@@ -0,0 +1,110 @@
|
||||
# beta.087 — Super piston et super piston gluant
|
||||
|
||||
## Contrat de sauvegarde avant implémentation
|
||||
|
||||
Assemblage volontaire à la clé dorée d'un carré plein de neuf pistons
|
||||
rétractés, identiques et orientés dans la même direction. Deux clics de
|
||||
confirmation ; les six directions sont admises. Sans cette action, les
|
||||
pistons restent indépendants. Aucun changement de la génération ni des
|
||||
registres de Fourneau et de Fût.
|
||||
|
||||
Les neuf composants deviennent des blocs `sanctuary:super_piston` ou
|
||||
`sanctuary:super_sticky_piston`, identifiés par leur orientation et leur
|
||||
position dans le carré. Le composant central porte une BlockEntity dédiée,
|
||||
schéma 1 : course engagée (0 à 3) et liste des déplacements natifs en cours.
|
||||
Les états intermédiaires utilisent les moving pistons
|
||||
natifs, avec leur état de bloc et progression sérialisés par Minecraft.
|
||||
Les pièces de tête et de tige sont des blocs techniques sans objet récupérable.
|
||||
Aucun inventaire ni copie de charge n'est conservé dans le contrôleur.
|
||||
|
||||
Un signal redstone sur un des neuf composants demande la sortie ; sa
|
||||
coupure demande le retour. Trois pas animés d'un bloc. Chaque pas est planifié
|
||||
entièrement avant mutation : obstacle intermédiaire, hauteur, frontière du
|
||||
monde, charge et présence des chunks. Aucune charge de chunk forcée.
|
||||
L'animation engagée finit avant d'entamer le pas suivant ou d'inverser.
|
||||
Après rechargement, les animations natives finissent et le contrôleur reprend
|
||||
à partir de l'état courant, sans rattrapage temporel ni restitution d'une
|
||||
copie initiale. Les sauvegardes suivent l'atomicité native des chunks ; pas de
|
||||
journal inter-chunks pour un crash brutal pendant une sauvegarde.
|
||||
|
||||
La charge commune conserve les règles natives d'indéplaçabilité et les
|
||||
liaisons slime/miel. Une poussée bloquée suspend l'ensemble de la tête ;
|
||||
une traction impossible laisse la charge en place et permet au gluant de
|
||||
rentrer, comme un piston natif. Les coffres et autres inventaires indéplaçables restent en place. Les blocs
|
||||
que les pistons natifs cassent, notamment les boîtes de Shulker, déposent
|
||||
leur objet avec son contenu.
|
||||
Le piston normal ne tire pas au retour. Les collisions et le déplacement des
|
||||
entités utilisent les moving pistons natifs.
|
||||
|
||||
Maj-clic avec la clé dissocie une machine rétractée et désalimentée. Une
|
||||
machine active demande de couper son alimentation et de la laisser rentrer.
|
||||
Casser une pièce dissocie la structure : les bases restantes redeviennent
|
||||
leurs pistons d'origine, les pièces techniques disparaissent sans butin ;
|
||||
seuls les composants effectivement cassés déposent leur piston. Les charges
|
||||
déjà déplacées restent à leur position actuelle, les animations de charge
|
||||
engagées finissent normalement. Une moitié déchargée attend son chargement
|
||||
pour valider ou nettoyer ses pièces ; aucun bloc étranger n'est écrasé.
|
||||
|
||||
## Valeurs et utilisation
|
||||
|
||||
Charge totale acceptée : **108 blocs distincts**, commune aux neuf cases,
|
||||
liaisons slime/miel incluses. Ce n'est pas une limite de 12 par colonne.
|
||||
Les neuf pistons doivent être du même type, orientés pareil, rétractés et
|
||||
sans alimentation. La clé dorée montre d'abord le carré ; un deuxième clic
|
||||
sous dix secondes confirme l'assemblage. Maj-clic sur un piston indépendant
|
||||
permet de l'orienter vers la face cliquée. Un carré ambigu dans une surface
|
||||
plus grande est refusé plutôt que de sélectionner des composants au hasard.
|
||||
|
||||
Un signal reçu par n'importe lequel des neuf composants fait avancer la tête
|
||||
commune jusqu'à trois blocs. La coupure la fait rentrer ; seule la variante
|
||||
gluante ramène la charge. Trois pas animés utilisent les collisions natives.
|
||||
Une charge en chunk absent suspend aussi le retour gluant, sans charger le
|
||||
chunk et sans l'abandonner comme si elle était un obstacle indéplaçable.
|
||||
|
||||
## Apparence
|
||||
|
||||
Les cinq PNG fournis sont conservés octet pour octet. Les faces 48 × 48 sont
|
||||
réparties sur les neuf composants ; la bande de côté 48 × 16 fait le tour
|
||||
du socle. **Les quatre pixels avant partent avec la tête** : le corps ouvert
|
||||
ne conserve que douze pixels, avec la texture intérieure reculée et une
|
||||
seule tige centrale qui comble l'intervalle. Les UV du côté sont découpés,
|
||||
non étirés. Modèles, collisions et retour animé suivent cette géométrie dans
|
||||
les six orientations, pour les deux variantes.
|
||||
|
||||
La synchronisation utilise les états et données des moving pistons natifs.
|
||||
Le client initialise la BlockEntity des seuls paquets marqués par cette
|
||||
machine avant leur chargement natif : un simple paquet d'état de bloc ne
|
||||
crée pas la BlockEntity d'un moving piston.
|
||||
|
||||
## Vérifications
|
||||
|
||||
Parcours natif dans un monde plat neuf, graine 87, serveur intégré : douze
|
||||
combinaisons direction/variante, assemblage réel à la clé, charge de 108,
|
||||
refus à 109, obstacle au deuxième pas puis reprise, coffre immobile avec son
|
||||
stock, boîte de Shulker cassée avec ses 17 diamants conservés, liaison slime
|
||||
au-delà de la face, séparation slime/miel, retour gluant, transport vertical
|
||||
d'une entité, coupure pendant l'animation, sérialisation des mouvements,
|
||||
déchargement puis retour dans les chunks et démontage après casse.
|
||||
|
||||
Le test vérifie aussi la réception côté client des têtes en mouvement et du
|
||||
retour final, les collisions de 12/4 pixels dans les six directions, le refus
|
||||
hors hauteur et la suspension sur un chunk absent sans le charger.
|
||||
Journal : `build/piston087-client.log` (succès, 1 min 20 s).
|
||||
Captures inspectées : `build/piston087-screenshots/`, notamment
|
||||
`0015_piston087-normal-face-open.png` et `0016_piston087-sticky-face-closed.png`.
|
||||
|
||||
Les essais à deux clients LAN distincts et avec un moteur de shaders tiers
|
||||
restent à réaliser. Aucun serveur dédié démarré et aucune EULA acceptée.
|
||||
|
||||
`check build assemblePack assembleTestPack` a réussi en 2 min 29 s
|
||||
(124 tâches, 104 exécutées), avec `:sanctuary:runGameTest` exclu pour respecter
|
||||
le choix de tests client uniquement. Journal : `build/piston087-check.log`.
|
||||
Le reçu `build/piston087-artifact.json` vérifie les 55 nouveaux assets, les
|
||||
13 nouvelles classes, l'identité des cinq PNG, la conservation des assets
|
||||
précédents, les sources embarquées et les archives. Les autres classes
|
||||
existantes restent identiques, à l'exception du raccord dans `Multiblocks`.
|
||||
|
||||
Archives locales : `build/Sanctuary-beta.087.mrpack` et
|
||||
`build/Sanctuary-Test-beta.087.mrpack`. Les archives beta.086 sont inchangées.
|
||||
Aucun déploiement dans Prism ni sur le canal publié ; aucun monde personnel
|
||||
modifié. Le pack de ressources intégré conserve sa version beta.070.
|
||||
@@ -0,0 +1,87 @@
|
||||
# beta.082 — nouvelles météos dans les commandes opérateur
|
||||
|
||||
Branche `codex/weather-commands-beta082`, Minecraft 26.3-pre-2, textures beta.070.
|
||||
|
||||
Les trois profils Sanctuary rejoignent la commande native :
|
||||
|
||||
- `/weather overcast` : ciel gris sans pluie.
|
||||
- `/weather fog` : brouillard.
|
||||
- `/weather showers` : averses alternant avec des périodes sèches.
|
||||
|
||||
Les six profils sont également disponibles sous le préfixe Sanctuary :
|
||||
|
||||
```text
|
||||
/sanctuary weather clear
|
||||
/sanctuary weather overcast
|
||||
/sanctuary weather fog
|
||||
/sanctuary weather showers
|
||||
/sanctuary weather rain
|
||||
/sanctuary weather thunder
|
||||
```
|
||||
|
||||
Ces choix nécessitent les droits opérateur et, en solo, Allow Commands.
|
||||
Ils sont masqués dans l’arbre transmis aux clients sans ces droits ; le
|
||||
serveur refuse aussi une commande envoyée directement sans autorisation.
|
||||
Le statut `/sanctuary weather` reste consultable normalement.
|
||||
La confirmation de sélection est traduite FR/EN.
|
||||
|
||||
## Durée et sauvegarde
|
||||
|
||||
Le choix porte sur la **journée civile courante**, dans le fuseau du monde.
|
||||
Il active le mode météo Real Time si la météo était en Vanilla, sans changer
|
||||
le mode du soleil. Il n’accepte pas de durée en ticks. Les averses conservent
|
||||
leurs passages de pluie et leurs pauses : les choisir ne force pas un départ
|
||||
immédiat de la pluie pendant un intervalle sec.
|
||||
|
||||
Le choix persiste après déconnexion, rechargement ou redémarrage. À la
|
||||
prochaine date civile, le tirage quotidien existant reprend. Rechoisir le
|
||||
même profil le même jour ne réécrit pas le journal. La sélection utilise
|
||||
exactement le schéma 1 existant (`schema`, `realtime`, `date`, `weather`) ;
|
||||
aucune migration de sauvegarde, dimension ou génération n’est introduite.
|
||||
L’écriture atomique précède la modification météo et sa synchronisation.
|
||||
Un conflit d’écriture refuse la modification sans écraser le fichier externe.
|
||||
|
||||
`/sanctuary weather vanilla` rend la main au cycle Minecraft ; les commandes
|
||||
natives `/weather clear`, `/weather rain` et `/weather thunder`, avec leurs
|
||||
durées habituelles, y fonctionnent comme avant. En mode Real Time, elles
|
||||
conservent leur message de redirection vers Vanilla ; les variantes sous
|
||||
`/sanctuary weather` sélectionnent les profils quotidiens correspondants.
|
||||
Les nouvelles commandes refusent la sélection si la météo Sanctuary est
|
||||
globalement désactivée ou indisponible dans ce monde.
|
||||
|
||||
## Vérifications
|
||||
|
||||
`Weather082ClientChecks` réussit en **49 secondes** : commandes envoyées
|
||||
par la connexion réelle du joueur, six profils, trois alias natifs,
|
||||
autocomplétion masquée puis réactivée avec Allow Commands, refus des commandes
|
||||
sans droits, état natif de pluie/orage et brouillard appliqué au rendu.
|
||||
|
||||
Le même scénario vérifie la sélection depuis Vanilla, l’indépendance du
|
||||
soleil, la conservation au rechargement, l’absence d’écriture pour une
|
||||
sélection identique, le passage à la date civile suivante, le retour aux
|
||||
commandes natives, la désactivation par configuration, le refus d’un conflit
|
||||
de sauvegarde avant mutation météo et les confirmations FR/EN.
|
||||
Journal : `build/weather082-client.log`.
|
||||
|
||||
Le contrôle existant `Weather057Smoke` est étendu aux six choix persistants,
|
||||
à leur relecture, au maintien pour la même date et au tirage du lendemain.
|
||||
`Weather057Smoke` passe **222 084 assertions**. La commande
|
||||
`check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
|
||||
réussit en **2 min 36 s**, 124 tâches (104 exécutées, 20 à jour).
|
||||
Journal : `build/weather082-check.log`.
|
||||
|
||||
Les 1 700 classes du JAR correspondent aux fichiers compilés ; les seules
|
||||
classes différentes de beta.081 sont le service météo, son état et le journal.
|
||||
Un libellé FR/EN ajouté ; textures, données et identifiants réseau inchangés.
|
||||
Sources et packs vérifiés, même JAR embarqué, archives beta.081 préservées.
|
||||
Reçu : `build/weather082-artifact.json`.
|
||||
|
||||
Les essais utilisent uniquement des mondes jetables et le serveur intégré ;
|
||||
aucun serveur dédié, EULA supplémentaire, monde personnel ou déploiement.
|
||||
|
||||
## Archives
|
||||
|
||||
- [Sanctuary-beta.082.mrpack](../build/Sanctuary-beta.082.mrpack).
|
||||
SHA-256 : `a1af14b31045c8e108a0f525098388aa4f3abc78cdb7f5141eb8cb6b9216e770`.
|
||||
- [Sanctuary-Test-beta.082.mrpack](../build/Sanctuary-Test-beta.082.mrpack).
|
||||
SHA-256 : `770952cf5c67af5bd135e4cd4ac093275407c3bd190396c0468bc36d2ca8212d`.
|
||||
Reference in New Issue
Block a user