CommandBlock Calcul généré par les commandes

  • Auteur de la discussion Auteur de la discussion KubbyDev
  • Date de début Date de début

KubbyDev

MapMaker de Time4Play, Créateur de OneCommand
28 Février 2014
53
12
78
Bonjour, j'aimerai savoir si il existe un site ou un moyen de tester expérimentalement l'impact de chaque commande sur les performances d'un serveur ainsi que l'impact des entitées et des command blocks en eux memes. Je fait des command blocks a un assez haut niveau donc des gros projets en général, je me préoccupe donc beaucoup du lag et je me pose souvent des questions du type: "Euh la c'est mieux de passer par un players operation sur une entité ou plusieurs commands blocks ?"

Du coup si quelqu'un connait un site qui montre comment sont gérées les entités, les command blocks ou les commandes par le jeu voir des benchmarks, ça m'interresse :)
Merci !
 
Salut Kubby :) comment va ? ^^

Je n'ai pas ce que tu cherches malheureusement, je me permet cependant de répondre, même si je doute t'apprendre quelque chose en disant ça, afin de partager une astuce que nous utilisons et qui semble plutôt bien fonctionner niveau optimisation des commandblock, astuce apprise via une vidéo de crushedpixel il me semble (plus sur du pseudo, mais c est un youtuber connu et plutôt très calé en commandblock, d'où le fait que je sois presque convaincu que tu connaisses aussi cette astuce):

- Éviter autant que possible d'activer plus de 63 commandblock dans un même chunk durant un même tick.
- Dans le cas où ce ne serait pas possible, faire de sorte que les commandblock (en nombre supérieur ou égal à 64 à être activés dans le même tick donc) soient rassemblés dans un seul et même sous-chunk.

Et sinon, ça me semble logique mais je ne l'ai pas vu réellement affirmé par qui que ce soit, donc c'est peut être une aberration de ma part, mais je le dis quand même, limiter le nombre de commandblock en mode repeat et actifs serait idéal.

Si ça ne te sert pas, ça servira peut être pour d'autres commandblocker, ou bien moi même si j'ai tout faux xD
 
Salut Kubby :) comment va ? ^^

Je n'ai pas ce que tu cherches malheureusement, je me permet cependant de répondre, même si je doute t'apprendre quelque chose en disant ça, afin de partager une astuce que nous utilisons et qui semble plutôt bien fonctionner niveau optimisation des commandblock, astuce apprise via une vidéo de crushedpixel il me semble (plus sur du pseudo, mais c est un youtuber connu et plutôt très calé en commandblock, d'où le fait que je sois presque convaincu que tu connaisses aussi cette astuce):

- Éviter autant que possible d'activer plus de 63 commandblock dans un même chunk durant un même tick.
- Dans le cas où ce ne serait pas possible, faire de sorte que les commandblock (en nombre supérieur ou égal à 64 à être activés dans le même tick donc) soient rassemblés dans un seul et même sous-chunk.

Et sinon, ça me semble logique mais je ne l'ai pas vu réellement affirmé par qui que ce soit, donc c'est peut être une aberration de ma part, mais je le dis quand même, limiter le nombre de commandblock en mode repeat et actifs serait idéal.

Si ça ne te sert pas, ça servira peut être pour d'autres commandblocker, ou bien moi même si j'ai tout faux xD
Salut !
Alors,
"Éviter autant que possible d'activer plus de 63 commandblock dans un même chunk durant un même tick."
ça c'est bon je sais, mais la ou c'est pas vrai c'est que c'est pas le fait d'avoir 63 cmd activés dans un meme chunk, mais d'avoir 63 actualisations de blocks dans un meme chunk. Du coup cette astuce etait efficace en 1.8, mais depuis la 1.9 il suffit de désactiver le TrackOutput des cmd (la 2e ligne) pour que ce soit bon. En fait la map witchery a été faite en grande partie avant que je découvre ça, du coup on avait des chutes de fps incompréhensibles au spawn (30 fps alors que mon pc fait tourner bf4 en ultra au calme). Apres avoir désactivé les TrackOutput on avait plus de problèmes. (Pour les désactiver utilise une tour avec des commandes de ce type: /blockdata ~ ~1 ~ {TrackOutput:0b})

En ce qui concerne les command blocks en mode repeat en fait ça dépend. Oui, c'est mieux de mettre le moins de repeat possible (j'ai fait le test, 13 chaines de 1000 command blocks génèrent plus de lag qu'une seule de 13000). Par contre, en plus de l'amélioration que ça apporte sur l'organisation, ça peut être pratique de diviser tes systèmes pour les mettre dans des smart clocks (Un command block en repeat qui teste une condition (par exemple pour un système qui donne des effets a un cheval, tu met testfor @e[type=Horse]), avec un autre en repeat conditionnal avant ta chaine). Attention aux smart clocks et aux problèmes d'ordre d'activation par contre :/ (je les met toutes en need redstone et les active par /fill en même temps que le reste du système (sachant que mes cmd sont en colonnes))

Voila donc comme tu peux le voir, j'ai déjà pas mal exploré tout ça, mais j'en veux toujours plus ! :p
 
  • J'aime
Reactions: Oromis
Heureux que tu te portes bien :)
Impeccable également me concernant je t'en remercie.

Salut !
Alors,
"Éviter autant que possible d'activer plus de 63 commandblock dans un même chunk durant un même tick."
ça c'est bon je sais, mais la ou c'est pas vrai c'est que c'est pas le fait d'avoir 63 cmd activés dans un meme chunk, mais d'avoir 63 actualisations de blocks dans un meme chunk. Du coup cette astuce etait efficace en 1.8, mais depuis la 1.9 il suffit de désactiver le TrackOutput des cmd (la 2e ligne) pour que ce soit bon. En fait la map witchery a été faite en grande partie avant que je découvre ça, du coup on avait des chutes de fps incompréhensibles au spawn (30 fps alors que mon pc fait tourner bf4 en ultra au calme). Apres avoir désactivé les TrackOutput on avait plus de problèmes. (Pour les désactiver utilise une tour avec des commandes de ce type: /blockdata ~ ~1 ~ {TrackOutput:0b})

Oui ou rafraîchissement comme tu dis.
Mais tu es sur que le fait que les commandblock soient activés n'est pas considéré comme une actualisation/un rafraîchissement de ces derniers ?
Comme il est demandé à chaque tick d'exécuter la commande y étant insérée, mise à part sous certaines conditions (block en conditionnal), nous l'avons compris ainsi de notre côté.

Concernant le trackoutput, nous avons toujours fait de sorte (que ce soit avant la 1.8 ou après) de désactiver la ligne qui nous informe de la réponse de l'action demandée au commandblock, dès la pose de ce dernier. Nous l'activons uniquement en cas de bug/problème à résoudre.
Nous savons donc que nos gains de performances ne sont pas dus à cela, mais c'est toujours bon à savoir que le fait d'activer ces lignes soit source de lag.
Merci pour l'info :)

En ce qui concerne les command blocks en mode repeat en fait ça dépend. Oui, c'est mieux de mettre le moins de repeat possible (j'ai fait le test, 13 chaines de 1000 command blocks génèrent plus de lag qu'une seule de 13000). Par contre, en plus de l'amélioration que ça apporte sur l'organisation, ça peut être pratique de diviser tes systèmes pour les mettre dans des smart clocks (Un command block en repeat qui teste une condition (par exemple pour un système qui donne des effets a un cheval, tu met testfor @e[type=Horse]), avec un autre en repeat conditionnal avant ta chaine). Attention aux smart clocks et aux problèmes d'ordre d'activation par contre :/ (je les met toutes en need redstone et les active par /fill en même temps que le reste du système (sachant que mes cmd sont en colonnes))
Limiter comme je le disais mais comme tu le dis il va de soit que lorsque la séparation des systèmes permet de garder inactifs des dizaines/centaines de commandblock, cela est à privilégier bien entendu.

Par contre tes commandblock étant en colonnes, tes /fill ne génèrent-ils pas justement un rafraîchissement dans un même tick d'un nombre de block supérieur ou égal à la limite des 64 block dont on parle lorsque tes systèmes concernés doivent être activés ?

Voila donc comme tu peux le voir, j'ai déjà pas mal exploré tout ça, mais j'en veux toujours plus ! :p

Je comprends, et je pense qu'on sera (je me permet de parler au nom de tous les amateurs de commandblock, et de tous les professionnels si il y en a qui se sentent de se qualifier ainsi) s'en cesse en quête de nouvelles informations/astuces pour nous permettre d'optimiser toujours plus nos systèmes et futures idées :)

Avec l'espoir qu'un jour, l'Elu qui en aura la connaissance osera s'arrêter ici faire glisser sa plume, nous guidant vers ce "Graal".

Amicalement.
 
  • J'aime
Reactions: Oromis et KubbyDev
Heureux que tu te portes bien :)
Impeccable également me concernant je t'en remercie.



Oui ou rafraîchissement comme tu dis.
Mais tu es sur que le fait que les commandblock soient activés n'est pas considéré comme une actualisation/un rafraîchissement de ces derniers ?
Comme il est demandé à chaque tick d'exécuter la commande y étant insérée, mise à part sous certaines conditions (block en conditionnal), nous l'avons compris ainsi de notre côté.

Concernant le trackoutput, nous avons toujours fait de sorte (que ce soit avant la 1.8 ou après) de désactiver la ligne qui nous informe de la réponse de l'action demandée au commandblock, dès la pose de ce dernier. Nous l'activons uniquement en cas de bug/problème à résoudre.
Nous savons donc que nos gains de performances ne sont pas dus à cela, mais c'est toujours bon à savoir que le fait d'activer ces lignes soit source de lag.
Merci pour l'info :)


Limiter comme je le disais mais comme tu le dis il va de soit que lorsque la séparation des systèmes permet de garder inactifs des dizaines/centaines de commandblock, cela est à privilégier bien entendu.

Par contre tes commandblock étant en colonnes, tes /fill ne génèrent-ils pas justement un rafraîchissement dans un même tick d'un nombre de block supérieur ou égal à la limite des 64 block dont on parle lorsque tes systèmes concernés doivent être activés ?



Je comprends, et je pense qu'on sera (je me permet de parler au nom de tous les amateurs de commandblock, et de tous les professionnels si il y en a qui se sentent de se qualifier ainsi) s'en cesse en quête de nouvelles informations/astuces pour nous permettre d'optimiser toujours plus nos systèmes et futures idées :)

Avec l'espoir qu'un jour, l'Elu qui en aura la connaissance osera s'arrêter ici faire glisser sa plume, nous guidant vers ce "Graal".

Amicalement.
Wow ta dernière phrase est vraiment classe x)

A vrai dire j'ai pas vraiment testé si le fait d'avoir 63 command blokcs par chunks réduisait vraiment le lag en 1.9, mais l'activation des commandes se fait coté serveur je pense, ça ne devrait pas avoir d'impact important sur le lag ni les performances.
EDIT: Je viens de tester, j'ai mis 63 command blocks/chunk dans 12 chunks, puis j'ai tout mis dans le meme, ça n'a rien changé au niveau performances, apres au niveau lag je sais pas mais je ne pense pas que ce soit important.

Voila voila, j'ai rien d'autre a ajouter... On attend l'Elu comme tu dis x)
 
  • J'aime
Reactions: PneuX