然后在偏东北的草方块上放如下五个命令方块并设置延迟：
0延迟：scoreboard players add @璐村惂鐢ㄦ埛_00000eP馃惥 AC_b 1
1延迟：scoreboard players add @a AC_a 1
2延迟：give @a[scores={AC_a=1, AC_b=1}] apple
3延迟：scoreboard objectives remove AC_a
4延迟：scoreboard objectives add AC_a dummy AC_a

2延迟命令方块的的 “@a[scores={AC_a=1, AC_b=1}]” 即为检测刚进入服务器的玩家的筛选条件

在偏东南的草方块上放如下五个命令方块并设置延迟：
0延迟：scoreboard players add @璐村惂鐢ㄦ埛_00000eP馃惥 AC_a 1
1延迟：scoreboard players add @a AC_b 1
2延迟：give @a[scores={AC_a=1, AC_b=1}] apple
3延迟：scoreboard objectives remove AC_b
4延迟：scoreboard objectives add AC_b dummy AC_b

2延迟命令方块的的 “@a[scores={AC_a=1, AC_b=1}]” 即为检测刚进入服务器的玩家的筛选条件

在偏西北的草方块上放置如下两个命令方块。延迟至少为5，下面 ≥ 北面：
草方块北面：fill ~ ~ ~4 ~1 ~ ~4 redstone_block
草方块下面：fill ~ ~1 ~ ~1 ~1 ~ air

在偏西南的草方块上放置如下两个命令方块。延迟至少为5，下面 ≥ 北面：
北面：fill ~ ~ ~-2 ~1 ~ ~-2 redstone_block
下面：fill ~ ~1 ~ ~1 ~1 ~ air

第二步：启动。
打掉草方块，在西侧本来有草方块的地方放置一个红石块

第三步：测试。
看到红石块循环在两组命令方块间出现则说明设置成功，此时退出游戏。

再进入服务器，它给了我们一个苹果然后就没有再给，说明成功了

教程部分就结束了，注意要用tickingarea把命令方块所在的区块设为常加载区块。
接下来是可靠性证明
（我是转场图）

首先了解一下这个系统的原理。
刚才我们放了四个草方块，北2个，南2个。就以它们为参照，把紧贴北边草方块的命令方块总结为【操作1】，紧贴南边的总结为【操作2】。
放置红石块和打掉红石块的命令方块的作用是执行下一步【操作】，因此不算进【操作】中。
①、②是给a、b加一，③是执行要对玩家使用的指令，④、⑤是重置计分项a或b

然后进行情景模拟。
考虑玩家进入服务器后，a、b的变化：
Ⅰ. 初始状态：玩家不在服务器时，a、b被轮流重置，所以a、b均为默认值0。
我们画一个圈表示这个状态。

Ⅱ. 接下来可能会出现两种情况：一种是执行操作1，另一种是执行操作2。
我们根据楼上的“最终结果”得到执行两种操作后的状态。

Ⅲ. 再接着，操作1和操作2循环执行，我们加上这两个箭头

可以发现，从初始状态开始，无论执行哪个操作，都会进入a=0, b=1 ↔ a=1, b=0的循环。

知道了计分项可能的状态，以及处于某一状态时，下一步会执行的操作，我们开始分析那些情况可以触发我们要执行的指令。
回头看看这两个操作，可以发现当且仅当执行操作前， a = 0, b = 0 时，操作1(或操作2)的第③步才会是a=1, b=1的状态。

由此更新状态转化图，绿色代表指令会执行，红色代表不会执行。

这就是玩家进入服务器后执行一次指令，此后不再执行的原理。

最后考虑的就是特殊情况了，如果玩家在操作正在执行时加入游戏，会发生什么？
因为【操作1】和【操作2】只是换了个清空对象，所以我们只需要考虑其中之一，就拿【操作1】下手：

【①执行后加入】
执行②后，状态变为：a = 1, b = 0
执行③，判断结果为失败
执行④、⑤，状态变为：a = 0, b = 0
变回了初始状态。
【②执行后加入】
执行③，此时状态为 a =0, b=0，判断结果为失败
执行④、⑤，状态仍为 a =0, b=0
变回了初始状态。
【③、④、⑤】
③只是一个判断操作，不会影响a、b
④、⑤只是对计分项进行重置，而初始状态本来就是重置后的状态，自然不会受影响。
变回了初始状态。
【结论】
玩家在操作执行时加入服务器，该操作完成后仍是初始状态，进行下一个操作时会被成功检测出来。

可靠性证明也完成了，此贴完结