sanctuary-beta/docs/redstone-computer-reference.md

Redstone Computer — référence et proposition pour Sanctuary

Lecture du 10 septembre 2026, WG-26. Référence locale demandée par l’auteur : /Users/koka/Documents/sanctuary/Redstone/redstone_computer. Le README et les sources ont été lus, sans compilation ni essai en jeu. Le manifeste indique Redstone Computer 2.0.0, Minecraft 26.1.2, auteur KOKA99CAB et licence GPL-3.0-or-later. Cette lecture ne vérifie pas un portage vers 26.3.

Le dossier historique 26.2/redstoner a été consulté ponctuellement pour sa VM. Ces deux références restent intactes. Aucune de leurs classes n’est importée dans Sanctuary par ce cahier.

Capacités retrouvées dans le code

Les trois profils sont définis dans program/ProgramTarget.java :

Machine historique	RAM en octets logiques	Budget d’instructions par tick
Redstone Computer 8 bits	256	96
Redstone Controller	1 024	256
Personal Computer	4 096	1 024

Ces valeurs décrivent l’ancienne version ; elles ne sont pas des réglages validés pour les futurs contrôleurs Sanctuary.

• vm/RedstoneProgram.java : assembleur interprété, labels, sauts, calculs, logique, registres A–D sur 8 bits, indicateurs de comparaison et RAM adressable.
• block/entity/RedstoneComputerBlockEntity.java : six faces de lecture/émission redstone 0–15, comparateur, impulsions, inventaire d’entrée/sortie, reconnaissance d’items et transfert conditionnel vers des inventaires adjacents.
• block/entity/BusConnectorBlockEntity.java, IoExtenderBlockEntity.java et DisplayMatrixBlockEntity.java : échanges cadencés, extensions d’entrées/sorties, affichages et adressage. Le mod dispose aussi d’un détecteur de pluie.
• src/client/java/fr/koka99cab/redstone_computer/gui/RedstoneComputerScreen.java : édition du code et exemples de porte logique, filtre d’items, relais de bus et mémoire commandée par une horloge.
• network/PersonalComputerNetworking.java : programmes enregistrés, catalogue public, contrôle à distance, gestion d’appareils associés et transfert de propriété.
• server/RedstoneComputerServer.java : lecture de collection, advancements et statistiques personnelles pour alimenter des programmes.
• server/ComputerNetworkService.java : appareils liés par identifiant et code, consultation de leur état et possibilité de garder leurs chunks chargés.

Le langage lit des ports et appelle les opérations définies par son interface Host. Dans le code parcouru, il ne fournit pas une instruction d’exécution arbitraire de commandes opérateur. Les transferts déplacent des items existants ; ce n’est pas une machine de création libre de blocs.

Points à reprendre autrement

Le processeur n’est pas continu dans cette référence. RedstoneProgram.tick crée un nouveau CPU et repart à l’instruction zéro à chaque tick. Registres, indicateurs et position d’exécution sont recréés. Le message de budget atteint n’implique pas une reprise à l’instruction suivante. La RAM, le programme, l’inventaire et les impulsions sont néanmoins sauvegardés par l’entité de bloc.

Le projet Sanctuary souhaite un ordinateur dont l’état complet peut être retrouvé. Cela demande de concevoir la continuité du processeur, ses attentes, ses arrêts et les opérations déjà effectuées, puis de les vérifier en sauvegarde et rechargement. La conservation de RAM seule ne suffit pas.

Les transferts sont limités jusqu’à 64 items par instruction, sans budget global de débit par machine. Les budgets de calcul historiques ne donnent donc pas à eux seuls un équilibre de production ou une garantie de performance du serveur. Un registre d’adresse doit aussi permettre d’exploiter la RAM étendue : un registre de données 8 bits seul ne couvre que 256 adresses en accès indirect.

L’ancien réseau autorise quatre appareils épinglés par profil et un plafond global de chunks forcés de 128 par défaut. Pour Sanctuary, le maintien en activité doit être raccordé au système Chunky et clés de chunk déjà prévu. Un programme ou un terminal réseau ne doit pas offrir un second accès gratuit à cette fonction.

Les connaissances et statistiques de l’ancien ordinateur font désormais doublon avec le Blocodex et le recensement Sanctuary : proposer des consommateurs de ce socle commun. Les compteurs exacts ne doivent pas être ramenés silencieusement à 255 pour tenir dans un registre ; une représentation ou un protocole est à choisir.

Les tests historiques lus portent notamment sur les impulsions et les profils mémoire. Ils ne constituent pas une validation du futur CPU continu, des actions matérielles ou de la charge d’un serveur Sanctuary.

Proposition : une grande puissance obtenue en survie

« Code légal » est compris ici comme une capacité très puissante construite et utilisée dans la partie, avec les ressources et déblocages du jeu. La puissance recherchée vient de ce que le joueur peut composer avec ses programmes.

Proposer un socle autonome de calcul et de redstone programmable, auquel Sanctuary raccorde ses fonctions particulières. Ce découpage est une proposition d’architecture, pas la création d’un nouveau mod ou d’identifiants.

Pouvoir proposé	Effet intéressant	Condition matérielle ou de progression
Circuits programmables	Horloges, mémoires, séquenceurs, serrures, ascenseurs, aiguillages et petits jeux.	Ports physiques, entrées réelles et exécution bornée.
Production pilotée	Reconnaître, compter, trier, traiter des lots et coordonner des machines.	Inventaires et périphériques accessibles ; débit de transfert explicite.
Programmes partageables	Récupérer, comprendre, adapter et transmettre un montage fonctionnel.	Code copiable, matériel à construire et autorisations propres à l’installation.
Construction assistée — piste ultérieure	Produire un plan, puis commander sa réalisation avec des matériaux connus.	Appareil de placement à concevoir, vraie réserve de blocs, zone et cadence définies. Connaître un matériau ne le fournit pas.
Installations spatiales Sanctuary	Préparer une expansion, établir une liaison ou piloter un accès à un espace.	Ancre, dépôt et autres appareils à définir ; destinations, ressources et déblocages validés côté serveur.

La liberté du langage doit permettre de créer des montages imprévus. Les limites portent sur la mémoire, le temps de calcul et les capacités des périphériques. Un code long attend son prochain budget ; il ne recommence pas silencieusement au début. Le premier budget n’est pas fixé par cette lecture.

La copie d’un programme est une manière de partager un savoir. Les joueurs peuvent construire et utiliser des installations communes sans tous devenir programmeurs. Les ruines pourraient fournir des montages lisibles par leurs anciens usages : pompage, orientation, production, puis opérations spatiales.

Le galactique conserve son rôle de langage opératoire proposé dans le cahier des machines. Les pouvoirs spatiaux demeurent soumis à leur progression, dont le déblocage collectif permanent des portails de minage. L’origine des glyphes et leur lien aux Endermen restent à écrire.

Première preuve jouable proposée

Le socle Sanctuary retient désormais trois blocs : contrôleur à six faces avec RAM intégrée, terminal et afficheur, plus les disquettes. L’assemblage du code est une fonction du terminal. Un compteur d’impulsions pilotant une porte suffirait à éprouver la première version avec les blocs redstone ordinaires, sans périphérique de manipulation d’items. Programme et état seraient inspectables, sauvegardés et repris après rechargement. Un autre joueur pourrait réutiliser le code avec son propre matériel. Le tri et les autres périphériques restent des extensions.

Cette preuve testerait la continuité du CPU, l’utilité en survie et le partage avant les fonctions spatiales. Taille mémoire, coût, alimentation, débit et forme des blocs restent à concevoir ensemble. Aucune livraison n’est lancée par cette proposition.