猫史档案馆

本技术难度:

★★★★★★☆☆☆☆

佼佼者专属

packet项目内容

hello everyone

欢迎来到c*的讲堂

本期包含大量知识点

祝您食用愉快( )

在此之前先创建几个鼠标

我们只需要这个角色就行了

--------------------------\

0.传输及内容格式

*成员行为就是鼠标

1.基础脚本

这里与你们通用的"略有不同"

由于协作机制类似房间

而且考虑到并不是很少人在协作(假设场景,你不会以为10个房间真够用罢())

云变量比云列表快

需要把云列表合并才能提高利用率

还要防止超出存储上限..........等

所以接下来你需要:

*分级解析

*1.扫描或创建房间(数据上传

*2.串联云变量&分段传输作品内容(实验性内容)

这个是我的独创技术

串联 就是把云变量联在一起

以利用单个云变量接近满载时剩余的50~4(而你浪费了更多())字符

不过我们这次只用一个云(

例图:

不过这里是从第一个字符出发,也用不到列表

从我的未制作完成的实验性项目packet里去来的积木

与本贴无关系(宣传实锤())

10·1024字符(+100%利用)

 

分段传输 把原数据分成若干份

逐个上传,另一端则合并"作品内容"里的信息

组成一个完整的信息链

但是这里并不是一下子上传1024字符

因为后面还有房间

所以限制每次上传100

然而bcm云变量延迟在17~13ms(1000ms=1s)

这只是在积木运行量 小时

如果算上这些: 80~600ms肯定有的

就以200ms为准

100*(1/延迟) ≈500字符/秒(占用其实只有100字符+编号;500%+利用)

很奇怪的计算公式,对吧( )

*3.时间线问题

延迟是建立网络体系(云变量的)的一喵烦

比如你上传了一段信息

过了一会儿

想去看看这个信息

却发现不在

因为被后来的人上传的覆盖了(ta在收到你的信息之前就发了)

因此要防止因延迟

在信息发出后等待一段时间

还要进行检测

如果发现被覆盖

就重新发出请求

*4.防止超出存储上限

这个问题你必需要考虑

如果你没有处理好

这将会让最后一个房间的人成为倒霉蛋(列表的x项不存在)

让后来者无法创作

或者让你掉头发()

你需要大量时间去找出问题所在

但却没有想到只是最后面的房间超出了总存储长度

导致数据结构被破坏

*5.内容更新

由于是以分级列表存储的:

像这样的一级一级往上修改合并/替换

以达到更新的效果(数据技巧)有时候还可以这样:

可以输出以","为分隔符的列表

2.丰富你的协作内容

本作者只给出了基本脚本模板

剩下的看你了()