141 lines
8.7 KiB
Markdown
141 lines
8.7 KiB
Markdown
# beta.038 — têtes-tombes, informations alimentaires et fondation des factions
|
||
|
||
Livraison beta.038 vérifiée. Cible exacte : Minecraft 26.3-pre-2.
|
||
|
||
## Contrat de mort et migration
|
||
|
||
La mort dans une partie Sanctuary place les objets normalement perdus dans une
|
||
`minecraft:player_head` portant le profil du défunt. Tout le monde peut la piller.
|
||
L’XP conserve sa règle actuelle (70 % en orbes). `keepInventory`, le mode
|
||
spectateur et la malédiction de disparition restent respectés.
|
||
|
||
Les anciennes sauvegardes d’inventaire ne changent pas. Seules les nouvelles
|
||
morts produisent des tombes. Les têtes ordinaires restent ordinaires. La tombe
|
||
utilise les composants natifs `minecraft:profile`, `minecraft:container` et
|
||
`minecraft:custom_data` (marqueur `sanctuary:grave`, schéma 1). Son contenu suit
|
||
la tête lorsqu’elle est cassée ou transportée. La tête vide conserve l’identité.
|
||
Aucun registre mondial supplémentaire, aucune réécriture de chunks ni migration
|
||
26.2. Retirer Sanctuary conserve les composants, mais supprime l’interface et
|
||
les protections spécifiques : vider les tombes avant de retirer le mod.
|
||
|
||
L’interface est un double coffre paginé pour accueillir les six rangées,
|
||
l’équipement, les accessoires et les objets en cours de manipulation. La tombe
|
||
est un coffre de récupération, sans dépôt de nouveaux objets. Toutes ses cases
|
||
sont grisées, y compris les cases vides ; les objets restent lumineux et retirables. Les fenêtres
|
||
partagent le même contenu côté serveur et deviennent invalides si leur support
|
||
disparaît. Le placement cherche un sol sûr proche dans les chunks chargés ; il
|
||
n’écrase aucun bloc. Les cas de lave et de vide ont un repli protégé.
|
||
|
||
## Informations alimentaires
|
||
|
||
AppleSkin officiel propose 3.0.10 pour 26.2, aucune version déclarée pour
|
||
26.3-pre-2 (API Modrinth et branches amont vérifiées le 14 septembre 2026).
|
||
Sanctuary reprend les indications dans son propre HUD : icônes de nourriture
|
||
et de saturation en infobulle, saturation actuelle, épuisement et aperçu de la
|
||
nourriture tenue. Le serveur fournit la saturation et l’épuisement réels ; les
|
||
aperçus respectent la capacité Hunger actuelle, dès trois icônes.
|
||
|
||
Cela ne change ni la valeur des aliments ni la vitesse de consommation ou de
|
||
régénération. Pas de nouvelle aptitude requise. Les préférences d’affichage
|
||
restent locales. Les sprites de faim vanilla restent la référence remplaçable
|
||
par le resource pack ; les contours AppleSkin sont un asset distinct crédité.
|
||
Aucune texture de respiration ne change.
|
||
|
||
## Utilisation et limites
|
||
|
||
Clic droit sur la tête posée : ouvrir. Le bouton `1 / 2` ou `2 / 2` change de
|
||
page quand le curseur est vide. Shift-clic extrait vers les rangées débloquées.
|
||
Le coffre permet la récupération, pas le dépôt de nouveaux objets. Casser la
|
||
tête, y compris en créatif, conserve les objets dans une tête transportable.
|
||
Clic droit dans le vide avec cette tête en main : ouvrir ; Maj + clic droit sur
|
||
un bloc : reposer. Aucun contenu n’est publié dans les mises à jour de chunks ;
|
||
seul le marqueur d’identité accompagne le rendu de la tête.
|
||
|
||
Le placement cherche à 12 blocs horizontalement et verticalement, sans charger
|
||
de chunks. Si cette zone est inutilisable, il essaie le dernier sol sûr observé
|
||
dans la même dimension pendant cette connexion. Sans sol utilisable, la tête
|
||
flotte près de la mort, au-dessus de la limite basse du monde ; le message donne
|
||
ses coordonnées. Cette tête ne disparaît pas au bout de cinq minutes et résiste
|
||
aux dégâts. Aucun terrain ni île n’est généré pour la récupérer.
|
||
|
||
AppleSkin est une intégration Sanctuary, pas un JAR 26.2 supposé compatible.
|
||
Les valeurs sont envoyées seulement au joueur concerné, au maximum quatre fois
|
||
par seconde lorsqu’elles changent. Un aperçu peut donc suivre la consommation
|
||
avec un retard maximal d’environ un quart de seconde à 20 TPS. Les infobulles
|
||
montrent deux rangées d’icônes, sans points chiffrés : nourriture native et
|
||
contours dorés de saturation. La part non absorbée maintenant reste assombrie
|
||
avec une légende. Les demi-icônes et fractions de saturation restent visibles.
|
||
Les bonus de saturation du cochon et de la mooshroom viennent des passifs
|
||
réellement actifs côté serveur. Les effets de potion et la régénération ne sont
|
||
pas prédits. Les textures et les crédits sont documentés dans [FOOD.md](../ressources-pack/sanctuary/FOOD.md).
|
||
|
||
## Vérifications
|
||
|
||
`./gradlew check build assemblePack assembleTestPack` passe en **4 min 30 s**,
|
||
avec **55 tests serveur** et les contrôles purs du dépôt. Le lot couvre les
|
||
inventaires complets, deux pages et deux pilleurs, les refus de dépôt (clic,
|
||
shift-clic, touche numérique et glisser), les protections lave/vide, le placement,
|
||
la casse créative et la sérialisation du contenu et de la mémoire du décès.
|
||
|
||
Les aperçus alimentaires sont comparés à la consommation Minecraft sur
|
||
**14 784 cas**, puis 18 consommations avec les passifs réels cochon/mooshroom.
|
||
La fondation est testée à zéro prestige : refus sans XP, coût exact de dix niveaux,
|
||
propriété et place unique, invitations refusées avant extension, charges de
|
||
prestige, reprise du paiement avant/après sauvegarde, mort et restauration
|
||
partielle refusée. Le contrôle pur relit un vrai journal schéma 1 sans changer
|
||
ses anciennes places/dépenses, puis vérifie sa mutation en schéma 2 et la
|
||
conversion unique de la configuration.
|
||
|
||
Le parcours graphique final passe en **45 s**, sur un monde plat de développement :
|
||
HUD à trois puis dix icônes, bonus serveur du familier, infobulles illustrées,
|
||
préférences FR/EN, ouverture réelle d’une tête par paquet, extraction sur les deux
|
||
pages, transport, informations de mort, GUI 1/2, puis création d’une faction par
|
||
les vrais boutons à prestige zéro. Treize captures sont conservées dans
|
||
`build/graves038-evidence/`, les logs dans `build/graves038-check-release.log` et
|
||
`build/graves038-client-ready.log`.
|
||
|
||
Les deux MRpacks ont été exportés et vérifiés : 1 381 classes Sanctuary,
|
||
dépendances et ressources embarquées identiques aux builds, trois classes du
|
||
module Test. Le profil plat ajoute uniquement ce module ; les MRpacks beta.037
|
||
restent inchangés. Reçu : `build/graves038-artifact.json`.
|
||
|
||
- [Pack normal](../build/Sanctuary-beta.038.mrpack).
|
||
- [Pack de test plat rapide](../build/Sanctuary-Test-beta.038.mrpack).
|
||
|
||
Ces tests ne constituent pas un essai prolongé sur un serveur public. Les seules
|
||
sauvegardes utilisées sont celles des dossiers de développement ignorés ; aucun
|
||
canal public, serveur personnel ni instance Prism n’a été mis à jour.
|
||
|
||
## Fondation des factions — contrat beta.038
|
||
|
||
La fondation devient accessible dès l’arrivée, sans prestige : **10 niveaux
|
||
entiers d’XP**, une seule place occupée par le fondateur, qui en est responsable.
|
||
Chaque place supplémentaire garde le prix en charges personnelles issu du
|
||
prestige (une charge par défaut). Les invités n’ont pas besoin de prestige.
|
||
Le départ et la dissolution ne remboursent pas la fondation.
|
||
|
||
Ce contrat autorise une lecture additive des journaux de cycles schéma 1 vers
|
||
schéma 2 : les anciens événements restent datés et valorisés en charges, sans
|
||
remboursement ni réduction des factions existantes. Les événements nouveaux
|
||
précisent leur monnaie (`charges` ou `levels`) ; l’identifiant
|
||
`sanctuary:faction_create` reste stable. La configuration schéma 1 est convertie
|
||
au chargement vers schéma 2 : `creationCost` est remplacé par
|
||
`creationLevels: 10`, `initialCapacity` devient 1. Les autres paramètres sont
|
||
conservés. Une configuration schéma 2 conserve son prix configuré.
|
||
|
||
Le serveur vérifie les niveaux avant d’écrire la fondation. Un reçu persistant
|
||
`sanctuary:faction_xp_paid`, sauvegardé avec l’XP du joueur et conservé à la mort,
|
||
empêche de payer deux fois après reconnexion. Si le journal a été écrit juste
|
||
avant un arrêt mais pas le joueur, le débit restant est repris avant toute autre
|
||
opération, puis avant un éventuel reset New Game+. Un reçu en avance sur le
|
||
journal est refusé comme restauration partielle. Aucune sauvegarde personnelle
|
||
n’est modifiée pendant le développement ; les anciens binaires ne doivent pas
|
||
relire un monde passé au schéma 2. Restaurer ensemble joueur et journal.
|
||
|
||
Les têtes enregistrent aussi l’identité, la date et l’heure civiles dans le
|
||
fuseau du serveur (celui de la machine en solo), le message natif de mort,
|
||
la dimension et les coordonnées du décès, distinctes du lieu sûr de dépôt.
|
||
Ces champs additifs du marqueur schéma 1 et le lore natif restent après vidage.
|
||
Le client et le serveur doivent tous deux être en beta.038 : le marqueur réseau
|
||
additif `sanctuary:faction_founding_levels_v1` vérifie la nouvelle politique.
|