119 lines
6.8 KiB
Markdown
119 lines
6.8 KiB
Markdown
# beta.040 — opérateur, habitant et ciel partagé
|
||
|
||
Branche `codex/operator-inhabitant-beta040`. Ticket issu des demandes du 14 septembre 2026.
|
||
|
||
## Contrat du mode opérateur
|
||
|
||
Dans une partie intégrée, **World Options → Allow Commands → Apply Changes**
|
||
active ou désactive le mode opérateur Sanctuary. Le réglage natif enregistré
|
||
fait autorité ; le mode créatif seul ne constitue pas une autorisation.
|
||
Il n'existe plus de second interrupteur opérateur propre à la carte ou aux
|
||
recettes. Sur serveur dédié, les droits sont ceux des opérateurs Minecraft :
|
||
un joueur distant ne peut pas s'attribuer ces droits depuis son interface.
|
||
|
||
Sans commandes, les contrôles réservés aux opérateurs sont invisibles et leurs
|
||
actions sont refusées côté serveur. Avec commandes, l'inspection de la carte,
|
||
le catalogue complet, les recettes complètes, les remboursements de compétences
|
||
et la remise à disposition du pouvoir du familier deviennent accessibles.
|
||
Le catalogue indique explicitement son mode opérateur. Couper les commandes
|
||
rétablit les filtres de découvertes et recettes, efface le terrain inspecté et
|
||
retire les contrôles, y compris lorsque le serveur intégré est en pause.
|
||
Les inspections n'accordent ni aptitude, ni découverte, ni recette persistante.
|
||
|
||
Les commandes d'administration Sanctuary utilisent la même règle. Les
|
||
outils de configuration native du monde réservés aux opérateurs sont masqués
|
||
hors de ce mode ; le réglage Allow Commands reste accessible à l'hôte selon
|
||
les conditions natives du jeu (notamment démo et hardcore).
|
||
|
||
## Fiche Habitant
|
||
|
||
La page reprend la sobriété de Hello World : personnage à gauche, familier à
|
||
droite et, entre les deux, les sections Nom, Biographie et Familier suivies de
|
||
leur contenu. Le nom conserve faction et prestige. Le nom personnalisé du
|
||
familier vient de son œuf équipé. Les textes d'aide sur le renommage, les
|
||
raccourcis et le consentement sont retirés de cette page ; restent le réglage
|
||
compact d'aide alliée et l'accès à l'historique.
|
||
|
||
Les aperçus ne font apparaître aucune entité de jeu et ne déclenchent pas d'IA.
|
||
Les modèles de bébé sont privilégiés, comme pour les familiers du monde.
|
||
|
||
Le cadrage du personnage tient compte de la largeur disponible : la hauteur
|
||
se réduit avant que les bras soient coupés. Le familier dispose de son propre
|
||
cadrage, adapté aussi aux grands modèles. Les textures existantes sont reprises.
|
||
|
||
Le HUD d’armure affiche uniquement les icônes pleines et les demi-icônes : les
|
||
emplacements vides sont supprimés, sans modifier les points de protection.
|
||
|
||
## Étoiles gagnées
|
||
|
||
Le ciel Sanctuary remplace les étoiles décoratives natives par un ciel partagé.
|
||
Avant tout événement, il est vide. Les événements enregistrés sont :
|
||
|
||
- première arrivée d'un habitant : une étoile, une seule fois pour son UUID ;
|
||
- advancement Minecraft accompli et normalement annonçable dans le chat : une
|
||
étoile pour une tâche, trois pour un objectif, cinq pour un défi. Les étoiles
|
||
supplémentaires restent proches de l'étoile principale ;
|
||
- prestige : une étoile pour chaque rang effectivement atteint ;
|
||
- faction atteignant deux membres, fondateur compris : une étoile.
|
||
|
||
Les critères partiels, recettes techniques, reconnexions, messages libres du
|
||
chat et créations de factions solitaires ne créent pas d'étoile. Couper les
|
||
annonces d'advancements dans les règles du monde ne coupe pas leur mémoire.
|
||
Un même advancement accompli par deux habitants donne deux groupes distincts ;
|
||
le retirer puis l'obtenir à nouveau avec le même habitant ne crée aucun doublon.
|
||
|
||
Une faction ne reçoit qu'une étoile à son premier duo. Le duo initial est
|
||
mémorisé indépendamment du nom et de l'identifiant de faction : dissoudre puis
|
||
recréer une faction avec ces deux mêmes personnes ne crée pas une autre étoile.
|
||
Un nouveau duo peut marquer une autre faction. Départs, exclusions et dissolution
|
||
ne retirent aucune étoile existante. Ce seuil remplace la proposition initiale
|
||
d'une étoile dès la fondation solitaire.
|
||
|
||
Les directions sont stables et communes aux clients du serveur. Le ciel
|
||
accomplit une rotation en sept jours réels, sur une référence UTC commune
|
||
synchronisée par le serveur. Le soleil et la lune conservent leur fonctionnement.
|
||
La visibilité nocturne et les effets de l'environnement restent natifs.
|
||
Le maillage graphique est conservé entre les images : il est reconstruit
|
||
seulement à l'arrivée de nouvelles étoiles ou lors du rechargement graphique.
|
||
Les deltas sont envoyés par lots ; les mouvements de caméra ne demandent aucun
|
||
calcul serveur et ne réattribuent pas les positions.
|
||
|
||
Le dessin passe par la méthode native de rendu des étoiles, pour conserver les
|
||
points d'intégration des moteurs de shaders. Un premier traitement Vanilla Light
|
||
est disponible dans les options ; voir [le contrat graphique](shaders-beta040.md)
|
||
pour son fonctionnement et l'état encore non validé des moteurs externes.
|
||
|
||
## Sauvegarde et reprise
|
||
|
||
Nouveau fichier additif `data/sanctuary-stars.json`, schéma 1, limité à
|
||
100 000 événements et 32 Mio. Chaque événement garde sa clé stable, son type,
|
||
l'habitant, son nom au moment de l'événement, sa source, sa date et son nombre
|
||
d'étoiles. L'écriture atomique vérifie le contenu précédent ; un fichier invalide
|
||
est préservé et suspend les ajouts, sans être remplacé par un ciel vide sauvegardé.
|
||
|
||
À la première ouverture avec ce système, les arrivées déjà attestées et le
|
||
journal des prestiges/factions sont repris. Les advancements déjà accomplis
|
||
sont repris à la connexion de leur habitant. Leur date d'étoile correspond à
|
||
cette reprise lorsque la date exacte n'est pas disponible. Les historiques
|
||
source, les sauvegardes personnelles et la génération des chunks ne sont pas
|
||
réécrits. Le journal stellaire ne dépend pas de l'inventaire ni du personnage
|
||
courant : mort et New Game+ conservent ses événements.
|
||
|
||
Le dessin de constellations, la sélection à la longue-vue et la consultation
|
||
Web ne sont pas inclus. Les événements structurés préparent ces usages sans
|
||
leur inventer d'interface dans cette livraison.
|
||
|
||
## Vérification
|
||
|
||
Les contrôles portent sur les autorisations et leur révocation, les tirages
|
||
stellaires déterministes, la sauvegarde/relecture, les vrais advancements,
|
||
le prestige, le seuil de deux membres et la conservation après dissolution.
|
||
Le parcours client utilise les boutons natifs de World Options, les aperçus
|
||
de plusieurs familiers et le rendu réel du ciel. `check build assemblePack
|
||
assembleTestPack` et 50 tests serveur passent, ainsi que le parcours client
|
||
natif avec les dernières modifications. Le test observe les appels de dessin
|
||
du HUD et le nombre d’indices de la passe stellaire native. Captures et reçu :
|
||
`build/operator040-evidence/final/`, `build/operator040-artifact.json`.
|
||
La connexion réseau dédiée n’a pas été testée ; le client à froid et le serveur
|
||
intégré ont été vérifiés.
|