下面的内容是圣天想要说明的技术细节，感兴趣可以看看，由我的小号代为转发：
自从小豆出了一条街是末地环的影片后，就让我设计一台珍珠炮前往末地环。当时并没有什么要求，但考虑到骗赞服的特殊性，设计之初就考虑了以下几点设计考量：
1, 蓄力要尽可能快，卡顿要尽可能低，而且卡顿波动一定要小；
2, 弱加载珍珠炮面板距离珍珠矫正距离太远，使用不方便，而且容易误加载，所以弱加载珍珠炮的入口最后靠近面板，但炮口要远离玩家常去的区域；
3, 骗赞服有很多常用东西在末地，例如全物品、熔炉组等，珍珠炮需要设计成矢量的，方便前往这些地方；
4, 末地环任何地方都要能抵达，这样方便未来按照方向或者区域化分末地环的用途；
5, 基于(3)，珍珠炮要能飞越全物品本体，以及未来的各种障碍物，所以炮口要尽可能的高；
此外，骗赞服还有以下的限制要注意
- 地毯的TNT优化会导致"风弹"出问题，一般情况下不开TNT优化；
- 不使用地毯的TNT聚合；
- 不使用其他激进的TNT优化；
考虑到以上几点，最后决定使用两台炮组合成服务器－客户端架构来设计。由于小豆的影片时间有限，很多优点都没办法完整的展示(当时我介绍给小豆就花了一个小时以上)。
在这个服务器－客户端架构中，弱加载珍珠炮就是服务器，提供弱加载服务，强加载珍珠炮就是客户端，可以访问弱加载获得弱加载服务。这样设计的最大好处就是稳定，即使弱加载坏掉，都不会影响强加载珍珠炮的任何功能。而且，未来还可以增加更多提供服务的珍珠炮，达成更复杂灵活的珍珠交通。此外，未来可以设计多个珍珠炮入口作为客户端，连结多个作为服务器的珍珠炮灵活地前往不同地方。
此外，服务器－客户端架构使得玩家可以减少操作次数，可以参考小豆第一次去边境的影片，要操作三次珍珠炮才能到边境，但如果使用服务器－客户端架构，也就是一次操作的事情。
为了珍珠炮能够稳定工作，这里的稳定指无论怎么玩，都要保证在任何玩家操作下都不会炸膛。
为了达成极高的稳定，炮口使用了向下矫正，并且通过纯时序规避违规操作。
向下矫正可以规避大叔炸炮。大叔多次炸炮都是因为珍珠向上的Y动量过大，导致珍珠误触到开火线路。但向下矫正的蜜块会大幅降低Y动能，规避极端动能的。同时，向下矫正也免去第二重的开火线，从而获得更稳定的结构。
时序方面，合理的时序分析能够规避互斥时间的发生。举个例子，在编码器编码的时候，某个时间会需要修改阵列的当量，但与此同时如果珍珠炮在复制TNT，就会发生问题，所以珍珠投入口要在某个指定时间关闭，这个事件可以通过时序分析得出【图一】。
大体上，在强加载开炮的时候，一条加载线会去加载弱加载珍珠炮以及沿途所需要的区块。同时，这条加载讯号也会为弱加载炮提供时序参考讯号。
在此之后，珍珠会进入到四个炮口中的其中一个。这四个炮口的位置摆放形成了一个完美的360度无死角。这边有限选择使用了四炮口而非单炮口的设计，单炮口的设计过于复杂，且过于复杂的设计却并没有为蓄力效率带来任何提升，致使效率还不如单炮口。就算引入ＥＭ炮口，单炮口的效率依旧不敌四炮口设计，所以设计之初就舍弃掉了单炮口设计。此外，既然使用了四炮口，ＥＭ炮口就不是必要的技术。因为骗赞服一般不开TNT优化，且没有激进的优化模组，所以使用ＥＭ炮口所获得的性能提升并不多，以至于最后没有使用ＥＭ炮口。而且，由于ＥＭ炮口会制造额外的复杂度，导致ＥＭ炮口与阵列的高效适配变得复杂。
########
在第一条影片发出的时候，就已经有人在质疑为什么不使用ＥＭ炮口，甚至有人找上了我，在此，我也会给予一个回应。要回应这个问题，首先应该问出一个很现实的问题：到底ＥＭ炮口真的有大家说的那么高性能吗？我给当时询问我的人问了一个问题：「在总共80MSPT的卡顿环境下，其中20MSPT是TNT爆炸造成的卡顿，考虑到ＥＭ炮口引入的其他卡顿，要如何达成净减少10MSPT？且TNT爆炸高度极高，无法使用任何非二次加速手段抵达。」
我做了一个理论计算，如果把这个设计改成ＥＭ炮口，只考虑爆炸的卡顿，不考虑引入的机械卡顿、ＴＮＴ运算卡顿等，理论卡顿减免为63%。但实际上，考虑到额外制造的机械卡顿和实体的移动卡顿等，根本无法减少10MSPT，所以骗赞服不是不用ＥＭ炮口，也不是不会设计，是没必要。
########
在珍珠在炮口进行矫正的同时，ＴＮＴ复制阵列同时也在准备。当珍珠刚完成好矫正的时候，ＴＮＴ复制阵列复制出的ＴＮＴ就已经抵达炮口并开始蓄力（此时，珍珠矫正甚至还没有归位）。同样的事情在很多地方都在发生，来获得最高的效率。例如说阵列编码器和复制讯号，由于阵列编码器的速度较慢，复制讯号的速度较快，所以编码器有优先清空发送讯号，然后复制讯号才会发出，这一快一慢的互补下，当ＴＮＴ阵列刚复制完，编码器就立刻请空了阵列的发射当量。通过这些极端的时序，骗赞服的弱加载珍珠炮才能最大化的节省时间，达成最高的效率。
但为了避免掉刻导致的效率下降，原本80MSPT的阵列就要修改，通过牺牲面积和材料，降低卡顿，成为了最终的设计。
########
在ＴＮＴ阵列的设计上，不管事最大卡顿还是平均卡顿，要尽可能的低，波动要尽可能小。想要让波动尽可能小，就不能使用当量太大的阵列，而且复制间隔不应该太大。当量过大的阵列会导致最大卡顿飙升，而且为了防止看门狗触发，一旦大当量的阵列复制后，就不能短时间内再次复制。看门狗不只是在ＭＳＰＴ超越60秒（预设数值）时会强行关闭服务器，当长时间维持高卡顿时，看门狗也会关闭服务器。所以为了避免看门狗强行关闭服务器，所以弱加载不能使用大阵列，最好就是小阵列配上高复制频率。此外，为了让骗赞服能在弱加载珍珠炮运行途中能够做点其他事情，卡顿最好不超过生存服的卡顿，不应该超过４０ＭＳＰＴ（含生存服基础卡顿）。
########
在经过小阵列不断复制蓄力后，珍珠会被送上世界高度外释放。为了避免珍珠太快掉回世界高度内，珍珠在释放之前补充Ｙ轴动能。整个珍珠炮设计这么高的原因，有一部分就是为了减少飞行器送珍珠的时间。不过，珍珠炮设计这么高还有一部分原因，就是为了规避建筑等障碍物。此外，此次珍珠炮的设计还有很多考量点，例如说阵列、珍珠矫正的回锁、编码器的选择。
########
这款被人不断诟病的「陈旧」阵列，也是考量点的一部分。在正片中大家能看到阵列炸了，可是大家没有看到的部分中，很少有人知道，这款阵列每次炸毁都发生在本体实装完成后。这台阵列现在被所有过往参与过这台阵列施工人的好评。不只是这一次，还包括过往的两台边境炮、返程炮等。虽然骗赞服不准用打印机，但如果在某个能使用打印机的服务器里面时装这台炮，打印机不管怎么造，只要是一层造完再造一层，就不可能爆炸，极其稳定。这种设计看起来老旧，但是对施工人员的难度却极低。
########
对于珍珠矫正的回锁，就如前面所提的是用时序来规避问题的发生，却不采用任何的其余结构，而且回锁结构保证一定能归位且没有响应延迟。称呼为回锁结构的原因是因为这需要整个锁定结构解锁且返回归位才能工作，既能锁住结构禁止作动，且要求结构完全解锁归位之后才能完全允许珍珠从缓存离开。
此外，编码器的选择也是重中之重，强加载和弱加载的编码器都不是同一款编码器，强加载要求迅速，弱加载要求数据吞吐量大，且方便存储，却不需要速度，所以双方各有侧重。强加载使用了分时复用版的时差编码，弱加载则是用上了分时复用版的串口，而且还会按照需求重新转码成速度更快的版本时差编码来调整阵列的当量。
最后也总结一下设计弱珍珠炮所需要考虑的内容。首先，弱加载不是强加载，不能混为一谈。其中炮口的设计、ＴＮＴ阵列的设计及配合、弱加载的加载及炮口协调都是重中之重。
炮口影响着效率，多少炮口以及多复杂的炮口影响着很多东西。到底是稳定性优先、效率优先还是维护优先。弱加载不同强加载，坏掉一般也不容易发现，如果稳定性不够顶尖的，就要考虑是否容易维护了。
此外，ＴＮＴ阵列的当量、复制间隔、机械卡顿、存活时间都是很重要的部分，尤其要注意卡顿波动和最大卡顿。切记不能在当量上贪大，要尽可能靠更高的复制频率来达成高效率而不是靠单次复制的当量，影响蓄力速度的不是单次当量，而是在相同的现实时间内能有多少ＴＮＴ能炸珍珠。也可以简单的通过一个评分系统来衡量设计的好坏，公式参考【图二】，分数越高越糟糕
（评分系统只作为参考，留下的两个系数是每个人心目中的权重，不同人之间不应该互相以此比较）。
最后，弱加载的加载及炮口协调也就只是时序要注意，没什么好说的，只是要多测试确保稳定就行，而且时序最好精确到每个ＧＴ。
对于骗赞服的这整个珍珠交通体系，重点在于编码器的设计以及讯号之间的处理，只要会算时序、对各种编码协议很了解的人。【图三】是当时设计时用来计算时序的图纸，可以参考看看。
