No mods Void storage

Oy oy.

La section manque un peu de no-mods ces derniers temps.
On va en rajouter un petit : je vous présente Void storage.

Ce petit module d'une soixante de commandes pour 16794 caractères va permettre de créer des petites "dimensions" de stockage.
L'avantage ? L'accès à une dimension est reservé à son créateur, ainsi, là où l'enderchest ne vous propose qu'un coffre, vous pourrez ici profiter d'un espace de 5x5x2 juste pour vous.

Chaque joueur peut créer plus d'une dimension, chacune étant différente et propre à son emplacement de création. Néanmoins, deux dimensions ne peuvent être proche de plus de 10 blocs en x et en z.

Un aperçu de la dimension :


Pour créer une dimension il vous suffit de jeter 4 crystaux de l'end et 1 sea lantern sur un enderchest se trouvant à la position où vous voulez placer votre portal :

(Vous ne pourrez faire cela que dans l'overworld, du fait que la dimension créée est dans les très basses couches du monde)

Pour quitter une dimension, il faut simplement vous tenir bien au milieu de la plateforme de celle-ci et sauter.

Pour détruire votre dimension, il suffit de dropper un bloc de tnt dans l'end_gateway (seul le propriétaire de la dimension peut la détruire) :


Pour ceux qui se posent la question "Pourquoi l'enderchest s'est transformé en end Gateway ?", c'est voulu, en fait c'est même l'inverse, la non transformation visuelle est un bug graphique réglé en quittant et rejoignant le monde (j'ai déjà essayé pas mal de fix sans succès, mais comme c'est peu génant ça restera tel quel).


Lien de la commande : http://pastebin.com/VvV3mgse

Voilà voilà.
Pour terminer, au lancement le module mettra un tellraw avec clickEvent pour set le world spawn sur votre emplacement. Le module doit obligatoirement se trouver dans les spawn chunks du world spawn pour fonctionner de n'importe où.

Et pour ceux qui veulent voir ce que ça donne en jeu, une petite vidéo de présentation made in @Zifiv :

[/QUOTE]​

 

@Zifiv Désolé de la lenteur de réponse

J'utilise de manière permanente ces trois commandes afin d'attribuer à chaque joueur un ID unique via un score :

Code (cpp):

scoreboard players operation @p[tag=!ID] ID = IDMax ID
execute @p[score_ID_min=1,tag=!ID] ~ ~ ~ scoreboard players add IDMax ID 1
scoreboard players tag @p[score_ID_min=1,tag=!ID] add ID

Tout joueur n'ayant pas le tag ID reçoit dans son objectif ID la valeur du même score du fakePlayer IDMax, puis il augmente le score du fakePlayer de 1 pour le joueur suivant et reçoit enfin le tag ID.
Le @p est important pour ne traiter qu'un joueur à la fois.
(Le score ID du fakeplayer IDMax est mis à 1 au lancement du module)

Lors de la création d'une dimension, un ArmorStand est summon au niveau de l'end Gateway et de nombreuse commandes sont exécutées sur lui. Celle concernant l'ID est celle-ci, elle donne le score ID du joueur le plus proche à l'ArmorStand :

Code (cpp):

execute @e[type=ArmorStand,name=Dimension,tag=!ID] ~ ~ ~ scoreboard players operation @e[type=ArmorStand,r=0,c=1] ID = @p ID

Alors oui il y a un risque la dimension se lie à un autre joueur dans le cas où deux seraient à cotés au moment de sa création, mais ça reste peu probable.

Les commandes pour vérifier le propriétaire sont les suivantes :

Code (cpp):

execute @e[type=ArmorStand,name=Dimension] ~ ~ ~ execute @a[r=2] ~ ~ ~ detect ~ ~ ~ minecraft:end_gateway -1 scoreboard players operation @p[r=0] Void = @e[type=ArmorStand,r=2,c=1,name=Dimension] ID
execute @a[score_Void_min=1] ~ ~ ~ scoreboard players operation @p[r=0] Void -= @p[r=0] ID

La première est un peu longue pour mettre quelques sécurités, mais en gros le joueur sur l'ArmorStand reçoit le score "ID" de celle-ci dans son score "Void", puis soustrait à son score "Void" son propre score "ID".
S'il a créé l'ArmorStand, sa valeur de "Void" est alors logiquement 0, ce que vérifie les autres commandes effectuant la téléportation.



Pour ce qui est de créer ces dimensions dans l'end, je doute fort de la réussite. Les TP se font pour l'instant en relatif par rapport à l'ArmorStand, hors il n'y a pas de relatif entre dimensions et il y aurait des problèmes pour les portails, ceux-ci n'emmenant pas où on le souhaite dans les dimensions, des ArmorStand ne seraient pas chargées.
Dans le module actuel, la création des ArmorStand dans l'end et le nether est d'ailleurs volontairement désactivée à cause des problèmes esthétiques que cela engendrerait dans les-dites dimensions.

 

Oui désolé, les vacances puis quelques problèmes de pc ont retardé la réponse

Si tu veux tout savoir, je sauvegarde toujours mes no-mods en fichier texte, donc si tu veux une liste des commandes, c'est facile à fournir sans avoir à décomposer le no-mod.

Je ne réalise pas de vidéos, ce n'est pas mon domaine. Si tu veux en faire tu en as bien sur le droit, et si tu as des questions je reste à disposition :)

 

Je mets le fichier texte en pièce jointe de ce message.
"INIT:" signifie que la commande n'est exécutée qu'une fois, à la création du module
"R:" signifie qu'il s'agit d'un command block à répétition (les autres étant en chain)
"COND:" signifie que le bloc est en conditionnal.

Le "R:COND:" à la seconde commande d'apparence useless est en fait une division par deux de la fréquence d'exécution, j'ai pris l'habitude d'en mettre à pas mal de mes modules pour réduire l'impact sur les performances, même si de base il est faible, vu que la majorité n'ont absolument pas besoin d'une exécution 20 fois par seconde.

Et yep, j'aime bien ta façon de présenter, donc je vais l'ajouter au post