Ajouter un terminal de stockage mural qui donne accès, depuis une seule interface scrollable, à tous les objets présents dans un ensemble contigu de coffres et de barils.
Le terminal doit être un équipement endgame de confort : on peut raisonnablement en fabriquer 1 à 4, mais en produire 20 à 40 doit demander un investissement important. Il ne doit pas être disponible dans le Shop.
Bloc et placement
Nouvel ID proposé : redstoner:storage_terminal.
Bloc mural orientable, haut d’un bloc mais épais d’environ une demi-dalle (8/16), posé dans l’espace libre contre la face horizontale d’un coffre ou d’un baril.
La face visible forme un écran ; le dos doit toucher directement un stockage compatible.
Si le bloc support disparaît ou cesse d’être compatible, le terminal se casse et se récupère.
Stockages compatibles pour le MVP : coffre, coffre piégé et baril vanilla. Le coffre de l’Ender est exclu.
Les stockages moddés pourront être ajoutés ensuite via un tag ou une API publique, sans dupliquer leur logique.
Réseau de stockage
À l’ouverture, le serveur part du stockage situé derrière le terminal et découvre tous les stockages compatibles reliés face contre face (haut, bas et quatre côtés), y compris les doubles coffres.
Le réseau reflète toujours les inventaires physiques : le terminal ne crée aucun stockage et ne copie aucun objet.
Les ajouts/retraits de coffres ou barils sont pris en compte sans casser la sauvegarde ; un écran ouvert se rafraîchit proprement.
Les chunks ne sont pas chargés de force.
La découverte, le nombre de conteneurs et les payloads doivent être bornés. Plafond MVP proposé : 128 blocs de stockage physiques par terminal (les deux moitiés d’un double coffre comptent séparément). Au-delà, afficher une erreur claire plutôt qu’un réseau partiel. Prévoir une pagination serveur : le client ne reçoit que les 54 entrées visibles et les métadonnées nécessaires.
Toute extraction ou insertion est validée côté serveur à partir de l’état réel des conteneurs afin d’éviter duplication, perte et désynchronisation multijoueur.
Interface
Un clic droit ouvre un écran de type grand coffre :
grille virtuelle de 9 × 6 entrées, inventaire joueur en dessous ;
molette et barre de défilement pour parcourir toutes les entrées ;
regroupement des piles strictement identiques (même item et mêmes composants/NBT), avec quantité totale affichée ;
clic gauche : retirer jusqu’à une pile ; clic droit : retirer une unité ;
shift-clic depuis l’inventaire joueur : déposer dans le premier emplacement compatible puis dans un emplacement vide ;
shift-clic depuis le terminal : retirer vers l’inventaire joueur ;
si le réseau change entre l’affichage et le clic, l’opération est recalculée ou refusée proprement, jamais appliquée à une ancienne référence.
La recherche textuelle, le tri avancé, l’accès distant et le sans-fil sont hors périmètre du MVP.
Progression et équilibrage
Recette proposée, à confirmer en playtest :
P G P
G C G
P T P
P : anotherworld:silver_plate ×4
G : minecraft:tinted_glass ×3
C : redstoner:controller ×1
T : anotherworld:titanium_ingot ×1
résultat : 1 terminal
Cette recette place le terminal après la chaîne ordinateur → contrôleur et l’accès au titane. Le coût cible est acceptable pour quelques points d’accès, mais devient volontairement lourd à grande échelle : 20 terminaux consomment notamment 20 contrôleurs, 20 lingots de titane et 80 plaques d’argent.
Le terminal reste visible en créatif et dans JEI, mais doit être explicitement exclu de toutes les sources d’achat et de loot de progression.
Propriété et intégration
Module propriétaire : Red-Stoner (bloc, découverte du réseau, menu, écran, règles de transfert).
Autre module appelé : Another World uniquement pour les composants de recette ; la dépendance Gradle redstoner -> anotherworld existe déjà.
API ou donnée partagée : inventaires vanilla publics ; prévoir un tag/API Red-Stoner pour de futurs stockages moddés.
Persistance : aucune base d’objets parallèle. Seuls les inventaires des conteneurs restent propriétaires des piles.
Réseau : incrémenter redstonerPROTOCOL_VERSION si de nouveaux payloads ou leur format sont ajoutés ; payloads paginés, bornés et validés côté serveur.
Compatibilité : nouvel ID sans changement des IDs ni des sauvegardes existantes.
Économie : ajouter des tests d’exclusion Shop/marché noir/lootboxes.
Découpage proposé
Enregistrer le bloc mural, son placement, ses modèles, son loot et les traductions FR/EN/RU.
Implémenter la découverte bornée des stockages contigus et les tests de topologie (simple, double coffre, branches, casse, chunks déchargés).
Ajouter le menu serveur autoritaire, la pagination et les tests de transferts/concurrence.
Ajouter l’écran 9 × 6, le scroll et les interactions souris/shift-clic.
Ajouter la recette endgame, les exclusions économiques, les tests associés et incrémenter la version de Red-Stoner.
Critères d’acceptation
Un terminal se pose uniquement sur la face horizontale valide d’un coffre, coffre piégé ou baril.
Il ouvre une vue scrollable de tous les objets accessibles dans le réseau contigu.
Les variantes avec composants/NBT différents ne sont jamais fusionnées.
Extraction, dépôt, shift-clic et concurrence multijoueur ne dupliquent ni ne perdent d’objet.
Casser ou ajouter un stockage rafraîchit le réseau proprement ; aucun chunk n’est chargé de force.
La découverte et les échanges réseau ont des limites explicites et testées.
Le terminal est craftable avec la recette endgame retenue et n’est achetable dans aucun catalogue.
Les traductions FR/EN/RU, tests ciblés et ./gradlew :redstoner:check sont ajoutés ; ./gradlew check réussit.
## Résultat joueur attendu
Ajouter un **terminal de stockage mural** qui donne accès, depuis une seule interface scrollable, à tous les objets présents dans un ensemble contigu de coffres et de barils.
Le terminal doit être un équipement **endgame de confort** : on peut raisonnablement en fabriquer 1 à 4, mais en produire 20 à 40 doit demander un investissement important. Il ne doit pas être disponible dans le Shop.
### Bloc et placement
- Nouvel ID proposé : `redstoner:storage_terminal`.
- Bloc mural orientable, haut d’un bloc mais épais d’environ une demi-dalle (8/16), posé dans l’espace libre contre la face horizontale d’un coffre ou d’un baril.
- La face visible forme un écran ; le dos doit toucher directement un stockage compatible.
- Si le bloc support disparaît ou cesse d’être compatible, le terminal se casse et se récupère.
- Stockages compatibles pour le MVP : coffre, coffre piégé et baril vanilla. Le coffre de l’Ender est exclu.
- Les stockages moddés pourront être ajoutés ensuite via un tag ou une API publique, sans dupliquer leur logique.
### Réseau de stockage
À l’ouverture, le serveur part du stockage situé derrière le terminal et découvre tous les stockages compatibles reliés **face contre face** (haut, bas et quatre côtés), y compris les doubles coffres.
- Le réseau reflète toujours les inventaires physiques : le terminal ne crée aucun stockage et ne copie aucun objet.
- Les ajouts/retraits de coffres ou barils sont pris en compte sans casser la sauvegarde ; un écran ouvert se rafraîchit proprement.
- Les chunks ne sont pas chargés de force.
- La découverte, le nombre de conteneurs et les payloads doivent être bornés. Plafond MVP proposé : **128 blocs de stockage physiques** par terminal (les deux moitiés d’un double coffre comptent séparément). Au-delà, afficher une erreur claire plutôt qu’un réseau partiel. Prévoir une pagination serveur : le client ne reçoit que les 54 entrées visibles et les métadonnées nécessaires.
- Toute extraction ou insertion est validée côté serveur à partir de l’état réel des conteneurs afin d’éviter duplication, perte et désynchronisation multijoueur.
### Interface
Un clic droit ouvre un écran de type grand coffre :
- grille virtuelle de **9 × 6** entrées, inventaire joueur en dessous ;
- molette et barre de défilement pour parcourir toutes les entrées ;
- regroupement des piles strictement identiques (même item et mêmes composants/NBT), avec quantité totale affichée ;
- clic gauche : retirer jusqu’à une pile ; clic droit : retirer une unité ;
- shift-clic depuis l’inventaire joueur : déposer dans le premier emplacement compatible puis dans un emplacement vide ;
- shift-clic depuis le terminal : retirer vers l’inventaire joueur ;
- si le réseau change entre l’affichage et le clic, l’opération est recalculée ou refusée proprement, jamais appliquée à une ancienne référence.
La recherche textuelle, le tri avancé, l’accès distant et le sans-fil sont hors périmètre du MVP.
## Progression et équilibrage
Recette proposée, à confirmer en playtest :
```text
P G P
G C G
P T P
```
- `P` : `anotherworld:silver_plate` ×4
- `G` : `minecraft:tinted_glass` ×3
- `C` : `redstoner:controller` ×1
- `T` : `anotherworld:titanium_ingot` ×1
- résultat : 1 terminal
Cette recette place le terminal après la chaîne ordinateur → contrôleur et l’accès au titane. Le coût cible est acceptable pour quelques points d’accès, mais devient volontairement lourd à grande échelle : 20 terminaux consomment notamment 20 contrôleurs, 20 lingots de titane et 80 plaques d’argent.
Le terminal reste visible en créatif et dans JEI, mais doit être explicitement exclu de toutes les sources d’achat et de loot de progression.
## Propriété et intégration
- Module propriétaire : **Red-Stoner** (bloc, découverte du réseau, menu, écran, règles de transfert).
- Autre module appelé : **Another World** uniquement pour les composants de recette ; la dépendance Gradle `redstoner -> anotherworld` existe déjà.
- API ou donnée partagée : inventaires vanilla publics ; prévoir un tag/API Red-Stoner pour de futurs stockages moddés.
- Persistance : aucune base d’objets parallèle. Seuls les inventaires des conteneurs restent propriétaires des piles.
- Réseau : incrémenter `redstoner` `PROTOCOL_VERSION` si de nouveaux payloads ou leur format sont ajoutés ; payloads paginés, bornés et validés côté serveur.
- Compatibilité : nouvel ID sans changement des IDs ni des sauvegardes existantes.
- Économie : ajouter des tests d’exclusion Shop/marché noir/lootboxes.
## Découpage proposé
1. Enregistrer le bloc mural, son placement, ses modèles, son loot et les traductions FR/EN/RU.
2. Implémenter la découverte bornée des stockages contigus et les tests de topologie (simple, double coffre, branches, casse, chunks déchargés).
3. Ajouter le menu serveur autoritaire, la pagination et les tests de transferts/concurrence.
4. Ajouter l’écran 9 × 6, le scroll et les interactions souris/shift-clic.
5. Ajouter la recette endgame, les exclusions économiques, les tests associés et incrémenter la version de Red-Stoner.
## Critères d’acceptation
- [ ] Un terminal se pose uniquement sur la face horizontale valide d’un coffre, coffre piégé ou baril.
- [ ] Il ouvre une vue scrollable de tous les objets accessibles dans le réseau contigu.
- [ ] Les variantes avec composants/NBT différents ne sont jamais fusionnées.
- [ ] Extraction, dépôt, shift-clic et concurrence multijoueur ne dupliquent ni ne perdent d’objet.
- [ ] Casser ou ajouter un stockage rafraîchit le réseau proprement ; aucun chunk n’est chargé de force.
- [ ] La découverte et les échanges réseau ont des limites explicites et testées.
- [ ] Le terminal est craftable avec la recette endgame retenue et n’est achetable dans aucun catalogue.
- [ ] Les traductions FR/EN/RU, tests ciblés et `./gradlew :redstoner:check` sont ajoutés ; `./gradlew check` réussit.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Résultat joueur attendu
Ajouter un terminal de stockage mural qui donne accès, depuis une seule interface scrollable, à tous les objets présents dans un ensemble contigu de coffres et de barils.
Le terminal doit être un équipement endgame de confort : on peut raisonnablement en fabriquer 1 à 4, mais en produire 20 à 40 doit demander un investissement important. Il ne doit pas être disponible dans le Shop.
Bloc et placement
redstoner:storage_terminal.Réseau de stockage
À l’ouverture, le serveur part du stockage situé derrière le terminal et découvre tous les stockages compatibles reliés face contre face (haut, bas et quatre côtés), y compris les doubles coffres.
Interface
Un clic droit ouvre un écran de type grand coffre :
La recherche textuelle, le tri avancé, l’accès distant et le sans-fil sont hors périmètre du MVP.
Progression et équilibrage
Recette proposée, à confirmer en playtest :
P:anotherworld:silver_plate×4G:minecraft:tinted_glass×3C:redstoner:controller×1T:anotherworld:titanium_ingot×1Cette recette place le terminal après la chaîne ordinateur → contrôleur et l’accès au titane. Le coût cible est acceptable pour quelques points d’accès, mais devient volontairement lourd à grande échelle : 20 terminaux consomment notamment 20 contrôleurs, 20 lingots de titane et 80 plaques d’argent.
Le terminal reste visible en créatif et dans JEI, mais doit être explicitement exclu de toutes les sources d’achat et de loot de progression.
Propriété et intégration
redstoner -> anotherworldexiste déjà.redstonerPROTOCOL_VERSIONsi de nouveaux payloads ou leur format sont ajoutés ; payloads paginés, bornés et validés côté serveur.Découpage proposé
Critères d’acceptation
./gradlew :redstoner:checksont ajoutés ;./gradlew checkréussit.