猫史档案馆

很多人都想实现这个功能，但是也有很多人反对

确实，单在局限于云模组里，没有可能

你不可能把10240玩成Infinity

 

当初我发了几篇秘籍，都是自己入猫以来总结的（没错一年半内容）

有位佬来到我贴里说我这是“笑话”

然后要我拿出实现过程

我一没电脑，二时间也快没了

作品是不可能了，月底也要到了

那么我这期贴说说这个想法

 

基本条件

云模组极限也就喵字符串

不允许你用列表套进去

怎么玩只能是这么多

有人用压缩算法，但是时间消耗会很大，不能用于即时联机

那么我们走到外面想一下

kt还有什么储存单位？

答：普通变量

→ 这有什么好说的？

你有想过变量有限制吗？好像没有

那么我们找到新载体了

→ 但是变量不能保存东西啊

别急，我后面讲

 

原理

→ 然后干嘛呢？

先想下咱们的云变量还有什么用途

→ 储存东西？

不只是

每一个修改的云变量上传到服务器，然后分发给每一个连接的设备

每一个设备都这样子做

那么，我们抽象一点，把云看成你家的路由器怎么样？

→ 路由器连接到网络上....

连接到玩家组成的蜘蛛网上

这个路由器变成了一个通道

云遍历的容量就是通道的容量（即带宽bandwidth）

→ 那么通道会干什么？

短暂地储存数据，数据保留直到被目的人接收或者超时自动删除

这些数据设计很像网络的数据包，一些元信息带一个很长的包裹

这个技术我称之为『packet』

 

数据设计

目的人id | 元数据 | part ; 数据（分段的）

这种字符串设计很简洁，解析不会太久

 

目的人id：指定谁接收

元数据：包裹信息

part：按照x长度分的数据的第part端

 

处理的方式与你设备联网的方式雷同

按照part拼接字符串

还可以根据附带信息对数据包解析不同的处理

然后将结果储存在变量里

 

由于这种技术引入了时间维度，可以达到“无限”的效果

在0.1s~0.3s可以完成一个packet的请求

在1s内满载可以通过40000+的字符串流量

但是有个不好的地方是，必须有人联机

最终还是要放回云端

但是在这里，压缩算法派上用场了

还有一点就是，制作时很容易出现概念误区

当时我packet停了很久

 

我不敢说首创，但是在bcm有这个技术的

我必定在前10

本技术是开源的

不像某些自私的，有技术不分享

还嘲讽别人