举例来说，比如我想让一个名为test的记分板在分数分别为1到10的时候执行不同的函数文件
我是写在同一个函数文件里面比较好，如：
execute if score XXX test matches 10 run ...
execute if score XXX test matches 9 run ...
execute if score XXX test matches 8 run ...
execute if score XXX test matches 7 run ...
等等
还是用函数文件嵌套的方式比较好？如
execute if score XXX test matches 10 run ...
execute if score XXX test matches 1..9 run function xxx:1
1.function
execute if score XXX test matches 9 run ...
execute if score XXX test matches 1..8 run function xxx:2
2.function
execute if score XXX test matches 8 run ...
execute if score XXX test matches 1..7 run function xxx:3
等等
还是说两种方式对于系统资源消耗其实没区别？
产生这种疑问主要是我自以为第一种方式，无论test分数是多少，这堆指令都要默默运行一遍，而第二种方法，比如一开始遇到的是10的话就只要运行两句话就行了？不知道想的对不对
我是写在同一个函数文件里面比较好，如：
execute if score XXX test matches 10 run ...
execute if score XXX test matches 9 run ...
execute if score XXX test matches 8 run ...
execute if score XXX test matches 7 run ...
等等
还是用函数文件嵌套的方式比较好？如
execute if score XXX test matches 10 run ...
execute if score XXX test matches 1..9 run function xxx:1
1.function
execute if score XXX test matches 9 run ...
execute if score XXX test matches 1..8 run function xxx:2
2.function
execute if score XXX test matches 8 run ...
execute if score XXX test matches 1..7 run function xxx:3
等等
还是说两种方式对于系统资源消耗其实没区别？
产生这种疑问主要是我自以为第一种方式，无论test分数是多少，这堆指令都要默默运行一遍，而第二种方法，比如一开始遇到的是10的话就只要运行两句话就行了？不知道想的对不对
对资源占用不是很了解，不过光从命令执行的条数来说，
你想的对。
不过在函数里用调用其他函数，也算一条指令（/function xxx:xxx）。
如果第二种方法一开始遇到的是1的话就有趣了
个人认为最节省资源的是二分法。
例如：
分数是 1..8，
可以分成两组：1..4 和 5..8，
如果在 1..4 里，则再分成两组：1..2 和 3..4，
如果在 1..2 里，则再分成 1 和 2。
当然这是在各种分数等概率出现的情况下。
一般是希望出现频率高的分数命令执行的次数少，出现频率低的分数命令执行的次数相对较多些。
莫名想到霍夫曼编码（跑
当然光一两条命令基本是看不出资源占用的变化是有多大的。
除非是一个浩大的工程，或者是批量生成 / 修改实体什么的
你想的对。
不过在函数里用调用其他函数，也算一条指令（/function xxx:xxx）。
如果第二种方法一开始遇到的是1的话就有趣了
个人认为最节省资源的是二分法。
例如：
分数是 1..8，
可以分成两组：1..4 和 5..8，
如果在 1..4 里，则再分成两组：1..2 和 3..4，
如果在 1..2 里，则再分成 1 和 2。
当然这是在各种分数等概率出现的情况下。
一般是希望出现频率高的分数命令执行的次数少，出现频率低的分数命令执行的次数相对较多些。
当然光一两条命令基本是看不出资源占用的变化是有多大的。
如果看命令数量的话，嵌套那种也不轻松呢，如果想节省资源可以降低这种检测函数的执行频率嘛。
Teenager_Yang 发表于 2019-7-15 22:15
对资源占用不是很了解，不过光从命令执行的条数来说，
你想的对。
不过在函数里用调用其他函数，也算一条指 ...
谢谢，感觉你说的有道理
本帖最后由 ⊙u⊙ 于 2019-7-15 23:55 编辑
嵌套不轻松，但就是能省...我个人理解，越想你的数据包省资源，指向的function就越频繁，也就越难看...
如果你是想往优化方面走的话，听我(和从大佬那里记来的小抄)几点...
ref...
https://minecraftcommands.github.io/commanders-handbook/
嵌套不轻松，但就是能省...我个人理解，越想你的数据包省资源，指向的function就越频繁，也就越难看...
如果你是想往优化方面走的话，听我(和从大佬那里记来的小抄)几点...
- 如你举的例子，你的想法很对，但问题楼上也提到了。
建立树形结构函数。看情况，一般是2分或者4分
http://www.mcbbs.net/thread-882962-1-1.html - 尽量减少重复的选择器使用，如
execute as @e[type=item,tag=1] run ...
execute as @e[type=item,tag=2] at run ...
execute as @e[type=item,scores={board=1..}] run ...
可变为
execute as @e[type=item] run function foo:next
#foo:next
execute if entity @s[tag=1] run ...
execute if entity @s[tag=2] at @s run ...
execute if score @s board matches 1.. run ...
差别是前者每次都从所有实体中挑一遍适格对象，后者从已经筛选过一次的池子中再次筛选
既是，减少使用@s以外的选择器。同时保持执行者的连贯性。 - 选择器的处理速度，由快到慢一般排列为 @s > 虚拟玩家 > UUID > @a > @e
- 选择器中的参数会按一定的顺序筛选对象。execute的执行顺序也是如此。所以中途条件不符的话就会停止此对象的匹配，继续挑选下一个对象。因此...
- 以下选择器参数填写时按这个顺序排列
type, gamemode, team, type!, tag, name, scores, advancements, nbt
尽可能使用type (@e[type=player]这种请改用@a...)
尽可能少用或不用nbt
nbt检测独特的几条就好，检测越多越慢。 - dx/dy/dz如果条件允许可以加上
ref...
https://minecraftcommands.github.io/commanders-handbook/
⊙u⊙ 发表于 2019-7-16 17:12
嵌套不轻松，但就是能省...我个人理解，越想你的数据包省资源，指向的function就越频繁，也就越难看...
如 ...
感谢！又学到一些优化的方法！