领达函数盒子系统

随着dnf游戏的不断发展，春节期间的各种活动也日益丰富。其中，春节礼盒的领取成为了玩家们关注的焦点。那么，在众多的礼盒中，我们应该如何选择呢？本文将为你详细解析各种礼盒的种类及奖励，并给出相应的选择建议。

二、盒子种类及奖励介绍

1. 普通盒子：开启条件较低，适合初入游戏的玩家或想要尝试获取一般奖励的玩家。奖励内容较为普通，但也有一定的机会获得珍贵道具。

2. 高级盒子：开启条件相对较高，适合有一定游戏经验的玩家。奖励内容较为丰富，包括稀有装备、材料、道具等，但获得高级奖励的概率相对较低。

3. 豪华盒子：开启条件较高，通常需要玩家达到一定的等级或完成特定任务。奖励内容较为豪华，包括珍稀装备、高价值材料、道具等，是许多玩家梦寐以求的奖励。

4. 至尊盒子：开启条件与限制较多，通常需要玩家购买或通过特定活动获得。奖励内容非常豪华，包括超级稀有的装备、材料、道具等，是dnf游戏中最顶级的奖励之一。

三、选择建议与注意事项

1. 根据角色需求选择：在选择礼盒时，应根据自己的角色当前阶段、培养目标、当前装备与技能来选择合适的礼盒。例如，如果你正在为某一副本苦恼缺少关键装备，那么豪华盒子可能就是你的更佳选择。

2. 理性消费与评估收益：在购买礼盒时，应量入为出，不要盲目追求高级奖励。同时，要评估收益与付出是否成正比，避免因过度消费影响其他方面的投入。

3. 与其他活动与福利的结合：在选择礼盒的同时，也要关注游戏内的其他活动与福利，如签到、任务、充值等，这些也可能为你提供丰富的奖励。

4. 注意事项与常见误区：在开启礼盒时，要确保账号安全，避免被盗号或被骗；同时，不要为了追求稀有度而盲目购买超限礼盒，避免浪费资源。

四、结语：dnf春节领哪个盒子2018，你的选择至关重要！在这个春节期间，选择合适的礼盒不仅能为你带来丰富的奖励，还能为你的角色培养和装备提升带来巨大的帮助。希望本文能为你提供有用的参考意见，祝你游戏愉快！

dnf春节领哪个盒子2018的介绍就聊到这里吧，感谢你花时间阅读本站内容，有关于其它相关信息别忘了在《九游》进行搜索哦！

期待已久的手游代号函数塔即将登陆九游，这款手机游戏吸引了大批玩家的关注，想下载这款游戏，有很多粉丝都在问九游小编代号函数塔好玩吗？代号函数塔值不值得玩？现在就为大家来简单分析下，看看这款游戏的玩法特点和游戏剧情介绍 。

代号函数塔快速预约/下载地址（需优先下载九游APP）：

》》》》》#代号函数塔#《《《《《

1、代号函数塔简要评析：

《代号：函数塔》是一款非正经都市奇幻手游。
“我”在叔叔的引荐下进入了梦寐以求的魂能者训练中心“艾启亚”，担任代理校长。
但从落地的那一刻起，事情就开始逐渐失去控制……
先是作为监考官，却在一场升级试监考中差点被送走……
继而发现声称有要事在身才离开艾启亚的叔叔，疑似身处某片度假海滩……

在这里，一切“我”以为的，好像都不是“我以为”的……
不像人的人，不像妖的妖，不正经的魂能者……还有离谱的异能？
仿佛反派BOSS才是这个世界里最正常的——至少目前看来是这样。

要解决五花八门的事件，化解各式各样的危机，“我”真的能信任这些……所谓的魂能者吗？

2、代号函数塔图片欣赏：

通过上面的游戏介绍和图片，可能大家对代号函数塔有大致的了解了，不过这么游戏要怎么样才能抢先体验到呢？不用担心，目前九游客户端已经开通了测试提醒了，通过在九游APP中搜索“代号函数塔”，点击右边的【订阅】或者是【开测提醒】，订阅游戏就不会错过最先的下载机会了咯！

云图计划战士函数怎么选？少前云图计划战士函数都是比较强力的函数，很多小伙伴不清楚战士的函数应该怎么选择，下面就来看看小编的战士推荐函数吧。

云图计划战士函数怎么选

1、命源流失，出现章节 1 4

评价：核心卡叠算力和失血增加能吸血和范围的算力战吼伤害，能给战士队一定的算力伤害，失血的衍生伤害多数情况下可以忽略不计。个人认为不是战士队的优先函数

泛用性：一般

2、暴烈突斩，出现章节 1 2 4

泛用性：较强

3、绝命强噬，出现章节 2 3

评价：越战力过图作用不大，一般血量都是满的，也不太需要吸血，但跨战力和打高难图必备。拿了这套函数的低血量战士才真的能做到输出比射手高，残血比盾肉，回血比奶快。

泛用性：较强。

4、超阈(yu)应激，出现章节 3

评价：个人认为这一套应该目前是战士最强的函数，加爆伤加暴击，还加攻速，把输出做到极致。就是完全体的不死战士。

泛用性：强!

总结：

战士的函数都非常强，没有不能用的。

命源流失算是这4套最差的一套，但也能提高一定的输出，暴烈突斩是平战力越战力最爽的一套但是跨战力有点吃力，绝命强噬加超阈(yu)应激直接化身高达，输出比射手高，回血比奶快。

以上就是关于云图计划战士函数的选择推荐了，希望这些内容能对大家有所帮助。更多的精彩内容请关注九游手游，这里一直会更新最新的手游攻略。

更多相关资讯攻略请关注：少前云图计划专题

不少卡关的小伙伴，一定都想知道少女前线云图计划函数怎么选，毕竟游戏内函数对于实力的提升是很大的。本期就给大家带来函数选择推荐，还不知道的小伙伴们，下面一起来看看吧。

——————【选择技巧】——————

目前已游戏内的主要输出还是战士为主，因为射手虽然输出很高，不过本身无法承受伤害，战士的函数是有着吸血以及真实伤害的效果，所以持续战斗能力是远远超过射手的。所以推本方面优先选择战士的函数。

如果大家有三星射手的话，那可以考虑1坦克1战术2射手1奶妈的阵容，这种配置则是极致的输出，函数方面优先选择射手，然后是奶妈。如果坦度不够可以选择双坦双射的体系，这种对角色的强度要求很高，但是输出也是最强的。

——————【注意事项】——————

游戏内除了套装函数以外，大家也可以选择在几个单个效果很强的函数作为辅助，例如破坏路障之后全体敌人眩晕，可以大幅度提升我们的坦度。开局之前还可以看看这一关究竟哪种职业比较合适。

关卡开始之前会给出提示，然后大家优先收集这个职业的套装函数即可，函数总的来说还是看大家阵容决定的，优先提升初始三星角色的威力，然后再去考虑2星角色。

以上就是本期少女前线云图计划函数怎么选的攻略，希望可以帮助到大家。

在前段时间魔兽世界更新了9.0版本，新版本的各种任务和活动都在等待着玩家去体验，不过因为是新版本，各种疑问还是比较多的，最近就有玩家不知道9.0版本春节礼包的盒子在哪领，我们来一起看一下吧。

牛牛年卡买了，228也买了，没看到哪里能领盒子啊?虽然我是非洲来的，万一今年欧了呢?

战网主页广告点进去不就有，领取我的盒子

我的世界1.12版本函数系统上线，那么我的世界函数系统与命令方块那个好用呢？下面九游小编就给大家带来我的世界函数系统与命令方块对比分析详解。

函数系统与命令方块的对比

进度作为函数的联动触发形式（），就不作过多讲解了。

前面讲到的三种模块中，对执行顺序无要求的高频模块无论是用函数还是CB都没有什么问题，而那些需要严格保证执行顺序的模块，以前我会将他们全部连在一起，只用一个 RCB(循环型命令方块，即高频CB源)作为“信号源”。

为什么不划出做成子模块(通常以ICB-脉冲型命令方块起头，后面跟一串CCB -连接型命令方块)调用呢?因为你在当前游戏刻调用了ICB子模块以后，它会等到下一个游戏刻才执行。可不要小看这一个游戏刻的延迟，它往往可能让你的系统出现意外，进而产生各种蜜汁bug。

而函数系统中，调用的子模块会立即插队执行，从而能够严格保证执行顺序，出错的可能性大大降低了。

函数系统不能够直接支持Conditional模式，也就是条件激活，而CB是支持的。关于这一点，以我个人的经验，影响是不大的，过去1.8没有

Conditional不也是这么过来了吗?

函数系统的主进程使用gamerule gameLoopFunction <命名空间:函数> 来挂载，而CB系统的"主进程"使用 RCB 作为高频信号源。

在过去的版本，通过glf挂载的主进程，其执行者是系统，也就是server。这个设定会产生各种各样的安全隐患，于是在后来的版本中，MOJANG将其执行者改成了glf所挂载的函数(前面也讲到了)。就目前而言，仅仅通过函数系统，就能够实现过去CB能够实现的功能，甚至还有一些是CB难以实现的功能。在这里就不过多讲了，希望对大家有所启发，可以研发各种各样的黑科技出来~

这里插入讲一点，想对于地图制作者来讲是绝对的福音。

mcf系统直接支持样式代码§。

CB系统的颜色黑科技什么的在这个面前根本不值一提。

资源占用方面，简单说一下个人的经验。

我们花了不到一天的时间把《喋血冰封II》升级到新的命令系统。新系统在资源占用方面明显比之前庞大的CB系统少了很多，流畅度不降反升，这也得益于函数系统更加接近游戏底层。CB系统在方块更新这一方面就输掉了一大截。更何况它需要占地。

试想一下，如果你的系统足够庞大，出生地可以加载的区域放多CB，你能够记得住吗?你在调试系统的时候，需要花多少时间去找到你要修改的指令呢?

此外，对于一些不放在出生点的模块，我们还需要考虑到区块加载的问题，相信这也是让许多人头疼的问题吧?

函数系统显然不需要担心这个，因为它所有的内容都保存在文件里，不具体地出现在游戏世界中，在资源占用方面相比与CB系统而言，是要占优的。

我们知道，写一个功能可能只要一两天，debug可能要一周。过去CB系统，不依靠编辑器的话，你得手动检查，如果要在中间插入什么指令的话，还得整体移动CB，实际工作效率是十分感人的;借助于编辑器，我们可以通过ooc导入的方式来实现快速修改

而函数系统呢?你需要改点什么，直接去翻文件改，改完了保存一下，再在游戏里通过/reload指令直接刷新，完事儿了。游戏都不用退出重进。

但凡地图制作者，知道了这些，都应该会心动的吧。

讲了这么多，相信大家对新系统也有一定的了解了，说不定已经激动得说不出话来了吧，那么更多内容就请大家自行去体验一下吧。在接下来的更新里，没准还会多出什么意想不到的东西呢!

如转载涉及版权等问题，请作者与我司联系，我司将在第一时间删除或支付稿酬。

《我的世界》1.12版本新增了函数命令这一内容，很多玩家觉得非常复杂，也有玩家发现这个命令可以完全脱离命令方块而存在，那么下面小编就为大家带来《我的世界》1.12函数命令系统入门教程，告诉大家函数命令怎么用，希望大家喜欢。

写在前面的话

1.9的更新为我们带来了三色命令方块，让命令方块脱离了红石成为独立的体系，我们因此可以更好实现一些想法；时隔3个版本，MOJANG再次为我们带来惊人的变革。

1.12中，函数与进度系统的出现，让命令脱离命令方块——这句曾经说过的玩笑般的预言，正式成为可能。

函数系统的构成

函数系统的由来

函数（function）系统，是 MC 1.12 Pre-1 版本中新增的一个功能，它将原来进度系统中返回指令的部分单独提取出来，做成了现在的函数系统。

函数系统的形式

函数系统由命名空间和函数文件组成，这些文件保存在存档目录/data/functions/下。functions目录下的文件夹，称为命名空间，各个命名空间下存放不同的函数文件。实际上，命名空间就是方便我们编写者分类并管理各种函数文件。

函数文件是以.mcfunction为后缀名的文本文件，建议采用utf-8无BOM编码以防显示错乱。简单来讲，一个函数等价于一个多行命令方块，函数文件里面每一行写一条指令，当执行这个函数时，里面的指令会按行依次执行。如果在一个函数中调用其它函数，那么在同一游戏刻，被调用的函数中所有指令先执行完，再继续当前函数中后续的指令，就像插队一样，我们在后面对比命令方块时还会说到这个。

请注意：在 1.12 Pre-3 版本中存在一个严重漏洞，即命令执行体不能正确地通过execute传递到被调用的函数中去，这个漏洞有望在后续版本以及正式版修复。

以下是本文用到的一个函数系统的目录，带有"+"的表示为目录

+ functions + say hi.mcfunction bye.mcfunction Text1.mcfunction text2.mcfunction + system + process _process.mcfunction _main.mcfunction player_tick.mcfunction

如何调用函数

在 1.12 中，MOJANG新增了function指令和一条名为gameLoopFunction的游戏规则来辅助我们使用函数系统。function指令的格式如下：

function <命名空间:函数名> function <命名空间:函数名> <if|unless> <选择器>

这两条都是可行的。其中，if|unless是在1.12 pre-4加入的功能，后面我会解释到这个。我们先来说说第一种形式。例如上面的目录中，要调用system这个命名空间下的_main文件，就是输入这样的指令：

function system:_main

现在，我们来看一个例子例如say命名空间下的Text1.mcfunction和text2.mcfunction，里面分别写上这些内容

Text1.mcfunction

#这是一个范例，在function文件中可以用#来注释行。请注意，不能够使用//来注释！ say 1 function say:text2 say 2

text2.mcfunction

say 3 say 4

当我在系统后台输入function say:text1时，聊天框会出现这些内容： [server] 1 [server] 3 [server] 4 [server] 2

也就是说，执行function指令的人，会把函数里面的指令依次执行——我在系统后台输入function指令，就是系统在执行，我自己输入function指令，就是我本人在执行。大家可能注意到了，函数中支持使用#进行注释（旧版本支持//注释，当前版本已经不再支持），也就是说被注释行不会作为指令而执行，这一点有多方便相比不比我再说了。同时需要大家注意：函数中所有指令不能够以/开头。例如，你可以这样写：

say @s

但是不能这样写：

/say @s

最后有一点需要注意的是，在function指令中调用函数时，不区分大小写。例如前面say命名空间下的Text1.mcfunction，我在调用的时候写的是say:text1

然后是第二种形式，也就是带有if|unless的。我简单举两个例子，大家就知道是什么意思了。

say:tellraw.mcfunction scoreboard objectives add timer dummy 计时器 scoreboard players add @s timer 1 function random:title if @s[score_timer_min=1200] scoreboard players reset @s[score_timer_min=1200] timer

random:title.mcfunction summon area_effect_cloud ~ ~ ~ {Tags:["rnd_title","rnd_title1"]} summon area_effect_cloud ~ ~ ~ {Tags:["rnd_title","rnd_title2"]} summon area_effect_cloud ~ ~ ~ {Tags:["rnd_title","rnd_title3"]} summon area_effect_cloud ~ ~ ~ {Tags:["rnd_title","rnd_title4"]} summon area_effect_cloud ~ ~ ~ {Tags:["rnd_title","rnd_title5"]} entitydata @r[r=0,type=area_effect_cloud,tag=rnd_title] {CustomName:"rnd_title"} execute @e[name=rnd_title,tag=rnd_title1] ~ ~ ~ tellraw @a[r=0,c=1] ["1"] execute @e[name=rnd_title,tag=rnd_title2] ~ ~ ~ tellraw @a[r=0,c=1] ["2"] execute @e[name=rnd_title,tag=rnd_title3] ~ ~ ~ tellraw @a[r=0,c=1] ["3"] execute @e[name=rnd_title,tag=rnd_title4] ~ ~ ~ tellraw @a[r=0,c=1] ["4"] execute @e[name=rnd_title,tag=rnd_title5] ~ ~ ~ tellraw @a[r=0,c=1] ["5"]

将say:tellraw放到主进程中

execute @a ~ ~ ~ function say:tellraw

则每位玩家每分钟将会看到1~5中随机一个数字出现在聊天框。也就是说，只有计时器分数满1200的人会执行后面的随机部分。那么很显然，带有if的意思就是，如果能找到后面的选择器，就执行这个函数，否则不执行。相当于testfor。

那么unless的意思也就很明显了：在找不到后面的选择器的时候，执行这个函数，相当于testfor+非门。

gameLoopFunction

讲完调用，就该讲讲高频了。玩命令方块的人都知道高频是实现许多功能的前提。在函数系统中，MOJANG 为我们提供了一条名为gameLoopFunction的游戏规则来实现高频。它的格式是

gamerule gameLoopFunction <命名空间:函数>

也就是说，你可以指定一个函数来高频执行，这个高频是20Hz的，也就是每一个游戏刻都会执行一遍。新建的存档如果没有执行过这条指令，而是用gamerule gameLoopFunction来查询的话，得到的返回值是-

为了方便，我们将这个规则简称为glf。在旧版本中，glf指定的函数，由系统（server）作为执行体；而在新的版本中，MOJANG 引入了虚拟执行体，例如将 say:text2 指定为glf时，每一个游戏刻得到的结果是这样的

[say:text2] 3 [say:text2] 4

也就是说，系统不再作为执行体，而是由虚拟的执行体代为执行。

关于 glf 多说两句。使用 glf 去高频执行一个函数，和使用 RCB（循环型命令方块，紫色那种）去执行，是不一样的。区别主要在于其更新顺序先后。一般而言不会造成严重影响，但是在某些情况会不一样。比如，使用 CB 能检测到生物的{HurtTime:10s}这个 NBT，而使用 glf 执行函数只能检测到的是{HurtTime:9s}，检测不到10，这是因为关于函数的更新，都放在了生物更新之后，而 CB 的更新则是在生物更新之前。详情可以看这里。按照 Searge 的说法，函数并不是命令方块的完全替代。这个说法，大家就见仁见智了。对我个人而言这个影响不大。

以上是函数系统的相关构成，以及如何调用函数。接下来我们来了解一下函数系统的模块分类。

函数系统的模块调用

对于一个完整的命令系统而言，模块一般可以分为三类：对执行顺序先后有要求的高频模块、对执行顺序先后无要求的高频模块、非高频模块。在函数系统中，我们同样可以将模块分成这三类。为了方便后续讲解。我们作这样的设定：

将 system:_main设为 glf ，并称之为主进程或者主时钟

对于上面讲到的三类模块，我们通过三种不同的方式去调用。

对执行顺序先后有要求的高频模块，在主进程中按照需要的顺序排列好来调用。对执行顺序先后没有要求的高频模块，在主进程中可以比较随意放置位置，但是一般不会考虑优先执行。特别地，如果这个模块是针对每一个玩家独立执行的，可以使用进度系统中的"tick"触发器来调用，而不需要放在主进程中。仅在特定情况下触发的非高频模块，在主进程中调用，但是辅以execute、scoreboard和选择器参数去控制其在合适的时候被调用，这里的选择器，包括了在1.12 pre-4中新增的if/unless的部分。

非高频模块在特定条件下激活，也在很大程度上减少了模块中大量重复出现execute的现象，并完全杜绝了超长的Conditional链，因为function中并不直接支持Conditional。不直接支持，说明可以间接支持，对吧。我们来看一个例子。

假设有红蓝两队，在开始前考虑到互殴问题不进行分队，而是采用挂tag的方式。 红队以tag=redTeam为标记，蓝队则以tag=blueTeam为标记，准备观战的玩家以tag=specTeam为标记 当玩家站在相应区域（红蓝两队的所有玩家还需要选择了职业）添加Ready的标记，视为准备就绪。 如果玩家不在相应区域时就移除Ready的标记。 选择了职业的玩家，其记分板项selectClass数值大于等于1 全部玩家准备就绪后，游戏进入倒计时，倒计时结束时游戏开始 倒计时未结束，有玩家脱离准备就绪的状态，则倒计时中断

条件比较多，我们先来看看怎么写这个模块，再进行分析。在这里，我们准备了一个名为gameStat的aec实体作为标记，所有游戏进程会以tag或者score的形式挂载到该实体上。请看指令部分

execute @p[tag=redTeam,score_selectClass_min=1] ~ ~ ~ execute @p[tag=blueTeam,score_selectClass_min=1] ~ ~ ~ scoreboard players tag @e[type=area_effect_cloud,name=gameStat,tag=notGaming] add allReady execute @p[tag=!Ready,m=2] ~ ~ ~ scoreboard players tag @e[name=gameStat,type=area_effect_cloud,tag=notGaming] remove allReady execute @p[tag=!Ready,m=2] ~ ~ ~ execute @e[name=gameStat,type=area_effect_cloud,tag=notGaming] ~ ~ ~ execute @s[tag=!allReady,score_waitTime_min=1] ~ ~ ~ title @a clear execute @p[tag=!Ready,m=2] ~ ~ ~ execute @e[name=gameStat,type=area_effect_cloud,tag=notGaming] ~ ~ ~ execute @s[tag=!allReady,score_waitTime_min=1] ~ ~ ~ title @a reset execute @p[tag=!Ready,m=2] ~ ~ ~ execute @e[name=gameStat,type=area_effect_cloud,tag=notGaming] ~ ~ ~ scoreboard players reset @s[tag=!allReady] waitTime scoreboard players add @e[name=gameStat,tag=allReady] waitTime 1 execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a times 10 140 10 execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"请玩家站在准备区域不要离开"}] execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a title [{"color":"yellow","text":"游戏即将开始"}] execute @e[name=gameStat,score_waitTime=40,score_waitTime_min=40] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"3"}] execute @e[name=gameStat,score_waitTime=40,score_waitTime_min=40] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime=60,score_waitTime_min=60] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"2"}] execute @e[name=gameStat,score_waitTime=60,score_waitTime_min=60] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime=80,score_waitTime_min=80] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"1"}] execute @e[name=gameStat,score_waitTime=80,score_waitTime_min=80] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime_min=100] ~ ~ ~ title @a times 10 30 10 execute @e[name=gameStat,score_waitTime_min=100] ~ ~ ~ title @a title [{"color":"gold","text":"游戏开始"}] scoreboard players set @e[name=gameStat,type=area_effect_cloud,score_waitTime_min=100] gameStat 1 scoreboard players reset @e[name=gameStat,score_gameStat_min=1,score_gameStat=1] waitTime scoreboard players tag @e[name=gameStat,score_gameStat_min=1,score_gameStat=1] remove allReady execute @e[type=area_effect_cloud,name=gameStat,score_gameStat_min=1,score_gameStat=1] ~ ~ ~ function system:StartGame

接下来我们来慢慢分析。

首先是开始的条件。有红蓝两队，那么这两队都肯定需要有人，才能够开始，考虑到同一选择器中不能重复使用tag的参数，我们保留了区分队伍的参数，而不是区分是否准备就绪的参数。因此，第一条指令的意思是，当存在选了职业并选红队的玩家以及选了职业并选蓝队的玩家，我们给中心实体加上allReady这个标记，以表明可能满足开始条件。

至于满足条件吗？如果有未准备就绪的玩家，就说明不满足，那我们就让一个没有准备就绪的玩家来去掉allReady这个标记好了。

对于3~5行，我们放后面点讲。先看后面。满足开始条件以后，我们会给中心实体加分（使用waitTime这个记分板项），在第一刻加分后出现提示文字提示准备开始，然后进入循环计时，最后计时满了，调用system:startgame这个函数来开始游戏（这里不是例子的部分，不作说明）。

那么回过头来看3~5行，这里明显是打断的部分。打断，就是要清掉提示文字、重置计时器。如果此时都还没有进行过加分，那么我们就不必进行那三条指令，因此可以看到中间有个选择器里有score_waitTime_min=1的参数加以限制。

重点来了，我们看到这3条指令前面相当长一串execute是重复的。因为在以前用cb写的时候，这里我使用了Conditional，而现在函数不直接支持Conditional，所以我用了一大堆execute，但是这里我们可以稍作修改，对不对？请看下面

execute @p[tag=redTeam,score_selectClass_min=1] ~ ~ ~ execute @p[tag=blueTeam,score_selectClass_min=1] ~ ~ ~ scoreboard players tag @e[type=area_effect_cloud,name=gameStat,tag=notGaming] add allReady execute @p[tag=!Ready,m=2] ~ ~ ~ scoreboard players tag @e[name=gameStat,type=area_effect_cloud,tag=notGaming] remove allReady execute @p[tag=!Ready,m=2] ~ ~ ~ execute @e[name=gameStat,type=area_effect_cloud,tag=notGaming] ~ ~ ~ execute @s[tag=!allReady,score_waitTime_min=1] ~ ~ ~ function system:cond_breakstartcount scoreboard players add @e[name=gameStat,tag=allReady] waitTime 1 execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a times 10 140 10 execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"请玩家站在准备区域不要离开"}] execute @e[name=gameStat,score_waitTime=1,score_waitTime_min=1] ~ ~ ~ title @a title [{"color":"yellow","text":"游戏即将开始"}] execute @e[name=gameStat,score_waitTime=40,score_waitTime_min=40] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"3"}] execute @e[name=gameStat,score_waitTime=40,score_waitTime_min=40] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime=60,score_waitTime_min=60] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"2"}] execute @e[name=gameStat,score_waitTime=60,score_waitTime_min=60] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime=80,score_waitTime_min=80] ~ ~ ~ title @a subtitle [{"color":"aqua","text":"1"}] execute @e[name=gameStat,score_waitTime=80,score_waitTime_min=80] ~ ~ ~ execute @a ~ ~ ~ playsound block.note.pling voice @p ~ ~ ~ 1 0 execute @e[name=gameStat,score_waitTime_min=100] ~ ~ ~ title @a times 10 30 10 execute @e[name=gameStat,score_waitTime_min=100] ~ ~ ~ title @a title [{"color":"gold","text":"游戏开始"}] scoreboard players set @e[name=gameStat,type=area_effect_cloud,score_waitTime_min=100] gameStat 1 scoreboard players reset @e[name=gameStat,score_gameStat_min=1,score_gameStat=1] waitTime scoreboard players tag @e[name=gameStat,score_gameStat_min=1,score_gameStat=1] remove allReady execute @e[type=area_effect_cloud,name=gameStat,score_gameStat_min=1,score_gameStat=1] ~ ~ ~ function system:StartGame

system:cond_breakstartcount.mcfunction

title @a clear title @a reset scoreboard players reset @s waitTime

虽然这个独立出来的子模块只有3条指令，但是如果分离出来的是30条而不是3条呢？能够节省多少功夫想必不需要我解释了吧？

以上是关于函数系统模块调用的部分，当中有提到使用进度系统来调用部分独立模块，我们接下来来讲这一部分。

函数系统与进度系统的联动

advancement，亦简称adv，目前wiki翻译叫进度。这里就不多作介绍了。在17w17b中MOJANG允许进度返回指令作为达成进度的奖励，让不少玩家发现了新大陆。随后在17w18b中，MOJANG进一步完善进度系统，使其可以完全独立于命令方块而建立起一个命令系统；在1.12 pre1中，MOJANG又作出了修改，将进度系统中的命令部分拿出来做成了如今的函数系统。

但是这并不意味着进度系统就不可以参与到命令系统中来，因为如今的进度系统可以返回函数作为达成进度的奖励。

相信很多人已经知道进度系统的结构了，但仍有相当一部分朋友还没有了解，在这里我们不妨来温习一下。

自定义的进度，所有文件都保存在存档目录/data/advancements/下，在这里新建的文件夹同样都称为命名空间，命名空间下存放各种进度文件。进度文件使用 json 格式。这里展示一个用于进度命令系统的例子

所涉及的两个文件分别是data/advancements/system/HelloTitle.json和data/functions/system/HelloTitle.mcfunction，这里进度和函数都用同样的命名空间和文件名方便记忆和管理，可以看到函数文件是 .mcfunction，而进度文件是 .json

system:HelloTitle.json

{ "criteria":{ "custom_name":{ "trigger":"minecraft:tick" } }, "rewards":{ "function":"system:hellotitle" } }

system:HelloTitle.mcfunction

#revoke adv，用于下次再激活 advancement revoke @s only system:hellotitle #命令部分 scoreboard objectives add helloTitle stat.leaveGame scoreboard players tag @s[tag=HelloTitle,score_helloTitle_min=1] remove HelloTitle tellraw @s[tag=!HelloTitle] ["",{"text":"Hello ","color":"yellow"},{"selector":"@s"},{"text":"! Welcome to Minecraft!","color":"yellow"}] scoreboard players tag @s[tag=!HelloTitle] add HelloTitle scoreboard players reset @s[score_helloTitle_min=1] helloTitle

这个进度会在下一个游戏刻达成，对象是全体在线玩家，达成进度后会执行HelloTitle.mcfunction中的指令。其实现的效果是，当玩家进入这个世界时，会在聊天框看见问候语（其他人看不到）。

可以看到，相比于以前命令方块高频，这里采用了进度系统的 tick 触发器和@s选择器。如果单纯用命令方块高频或者函数系统，那么只需要这样

scoreboard objectives add helloTitle stat.leaveGame scoreboard players tag @a[tag=HelloTitle,score_helloTitle_min=1] remove HelloTitle execute @a[tag=!HelloTitle] ~ ~ ~ tellraw @s ["",{"text":"Hello ","color":"yellow"},{"selector":"@s"},{"text":"! Welcome to Minecraft!","color":"yellow"}] scoreboard players tag @a[tag=!HelloTitle] add HelloTitle scoreboard players reset @a[score_helloTitle_min=1] helloTitle

区别就是选择器上的不一样。如果大家觉得进度系统很麻烦，可以不去使用，但是接下来我们会看到一个使用进度系统的其他触发器来调用函数的例子。例如，要让所有冒险模式玩家入水即死。

rules:DieInWater.json

{ "criteria":{ "1":{ "trigger":"enter_block", "condition":{ "block":"water" } } }, "rewards":{ "function":"rules:dieinwater" } }

rules:DieInWater.mcfunction

#revoke advancement revoke @s only rules:dieinwater #commands scoreboard players tag @p[m=2,r=0] add waterKill execute @s[tag=waterKill] ~ ~ ~ tellraw @a [{"selector":"@s"},{"color":"white","text":" 被水淹没了"}] execute @s[tag=waterKill] ~ ~ ~ gamerule showDeathMessages false kill @s[tag=waterKill] execute @s[tag=waterKill] ~ ~ ~ gamerule showDeathMessages true scoreboard players tag @s[tag=waterKill] remove waterKill

当玩家踏入水中时，我们要给玩家加上一个tag，然后杀掉他。至于为什么用@p而不用@s呢？因为@p不能选中死人，而@s可以，如果不想看到聊天框刷屏，就不要选择用@s。

以上是利用进度系统的 enter_block(玩家进入方块) 这一触发器来实现落水即死功能的，如果单纯依靠函数，不依靠进度系统去实现的话，可以这样写

rules:DieInWater_FUNCONLY.mcfunction

execute @a[m=2] ~ ~ ~ detect ~ ~ ~ water -1 scoreboard players tag @p[r=0] add waterKill execute @a[tag=waterKill] ~ ~ ~ tellraw @a [{"selector":"@s"},{"color":"white","text":" 被水淹没了"}] execute @a[tag=waterKill] ~ ~ ~ gamerule showDeathMessages false kill @a[tag=waterKill] execute @a[tag=waterKill] ~ ~ ~ gamerule showDeathMessages true scoreboard players tag @a[tag=waterKill] remove waterKill

然后将这个函数扔进主进程中高频执行即可。

我们讲完了函数系统与进度系统的联动部分。道理而言已经讲完了函数系统的基础使用，那么在最后，我们来聊聊函数系统与命令方块系统的对比吧，看看它们各自的优缺点。

函数系统与命令方块的对比

如果你看上面的看得有点迷糊，那我们来简单讲讲函数系统和命令方块(CB)系统的对比吧，进度作为函数的联动触发形式，就不作过多讲解了。

前面讲到的三种模块中，对执行顺序无要求的高频模块无论是用函数还是CB都没有什么问题，而那些需要严格保证执行顺序的模块，以前我会将他们全部连在一起，只用一个 RCB（循环型命令方块，即高频CB源）作为“信号源”。

为什么不划出做成子模块（通常以ICB-脉冲型命令方块起头，后面跟一串CCB -连接型命令方块）调用呢？因为你在当前游戏刻调用了ICB子模块以后，它会等到下一个游戏刻才执行。可不要小看这一个游戏刻的延迟，它往往可能让你的系统出现意外，进而产生各种蜜汁bug。

而函数系统中，调用的子模块会立即插队执行，从而能够严格保证执行顺序，出错的可能性大大降低了。

函数系统不能够直接支持Conditional模式，也就是条件激活，而CB是支持的。关于这一点，以我个人的经验，影响是不大的，过去1.8没有

Conditional不也是这么过来了吗？

函数系统的主进程使用gamerule gameLoopFunction <命名空间:函数>来挂载，而CB系统的"主进程"使用 RCB 作为高频信号源。

在过去的版本，通过glf挂载的主进程，其执行者是系统，也就是server。这个设定会产生各种各样的安全隐患，于是在后来的版本中，MOJANG将其执行者改成了glf所挂载的函数（前面也讲到了）。就目前而言，仅仅通过函数系统，就能够实现过去CB能够实现的功能，甚至还有一些是CB难以实现的功能。在这里就不过多讲了，希望对大家有所启发，可以研发各种各样的黑科技出来~

这里插入讲一点，我想对于地图制作者来讲是绝对的福音。

mcf系统直接支持样式代码§。

CB系统的颜色黑科技什么的在这个面前根本不值一提。

资源占用方面，简单说一下我个人的经验。

我们花了不到一天的时间把《喋血冰封II》升级到新的命令系统。新系统在资源占用方面明显比之前庞大的CB系统少了很多，流畅度不降反升，这也得益于函数系统更加接近游戏底层。CB系统在方块更新这一方面就输掉了一大截。更何况它需要占地。

试想一下，如果你的系统足够庞大，出生地可以加载的区域放多CB，你能够记得住吗？你在调试系统的时候，需要花多少时间去找到你要修改的指令呢？

此外，对于一些不放在出生点的模块，我们还需要考虑到区块加载的问题，相信这也是让许多人头疼的问题吧？

函数系统显然不需要担心这个，因为它所有的内容都保存在文件里，不具体地出现在游戏世界中，在资源占用方面相比与CB系统而言，是要占优的。

我们知道，写一个功能可能只要一两天，debug可能要一周。过去CB系统，不依靠编辑器的话，你得手动检查，如果要在中间插入什么指令的话，还得整体移动CB，实际工作效率是十分感人的；借助于编辑器，我们可以通过ooc导入的方式来实现快速修改

而函数系统呢？你需要改点什么，直接去翻文件改，改完了保存一下，再在游戏里通过/reload指令直接刷新，完事儿了。游戏都不用退出重进。

但凡地图制作者，知道了这些，都应该会心动的吧。

讲了这么多，相信大家对新系统也有一定的了解了，说不定已经激动得说不出话来了吧，那么更多内容就请大家自行去体验一下吧。在接下来的更新里，没准还会多出什么意想不到的东西呢！

如转载涉及版权等问题，请作者与我司联系，我司将在第一时间删除或支付稿酬。