这东西我在 tmi2_v3_改 实验过确认是可行的。 以炙蚁地狱区域为例，底下是该区域的其中一个房间的资料: > da here Object : 房间(/u/p/ppl/hiei/redant/010) exits : ([ "south" : "/u/p/ppl/hiei/redant/026", "west" : "/u/p/ppl/hiei/redant/009" ]) exits_color :"1;31m" light : 1 long : "洞穴十分狭小，你得屈着身体才能前进，嘎吱嘎吱的走动声音 不\n时悠q洞穴的深处传来，在洞穴里久居的怪物，对於自己送上门来\n的食物想必 感到非常兴奋吧『C\n\n" reborn_times :1463620349 room_file :"010" short : "炙蚁地穴-第一层" 以艾恩葛朗特的区域为例，因为预设其会有 100 层区域(实际 99 层)， 因此区域目录的形式会如下图: /u/s/sao/层数编号/区域编号/段数编号/ 例如起始城镇的第一格房间档: /u/s/sao/01/01/1/001.c 未来则会有个 区域名→编号编码 的对照资料，因此实际上，该地图资 料被储存於玩家资料区的情况如下: maps : ([ "层数编号" : ([ "区域编号-段数编号" : "字串值", ]), ]); 区域有分段(层)的情况下，我是预设最多不会超过 512 个房间，因此， 假设最多 512 个房间，每个房间有无走过的情况用 0 与 1 来区别时: 11111111111111111001010010010101010000101..............01001010 长度共 512 取前八个 11111111 为例，如果假设它是一个二进制的东西时: (11111111) = 255 (三位数) 2 10 则上面的长度 512 的东西可拆解为 "255,......"，长度就变为: 512/8 = 64, 64x(3+1)-1 = 255 从上面大致可发现「取越长的段落来做 2→10 进位会越有利」。 比方我们取前 16 个 1111111111111111 (1111111111111111) = 65535 2 10 则上面的长度 512 的东西可拆解为 "65535,...."，长度就变为: 512/16 = 32, 32x(5+1)-1 = 191 那麽实务上的做法是如何呢？它首先会读入该区域总共有几格的资 料，会先得到一个 n，接着判断玩家有没有该区域资料字串值，没 有的话就先产生出来: for(i=0;i<n;i++) str+="0"; 接着，假设玩家进去该区域的第一个房间编号是 k: str[k-1]='1'; 接着对这个 str 做拆解: for(i=0;i<n;i=i+16) { if(i+15>=n) tmp=str[i..n-1]; else tmp=str[i..i+15]; x=hex10(atoi(tmp)); new_str+=x+","; } 这样 new_str 就是上面的 "65535,..." 这样的形式。 拆解的方式很多，事实上我不认为这是最理想的，理论上应该有更 佳的做法，兼顾可容许的字串长度以及可负荷的换算复杂度。 (例如 "717277566556262511" 这样的字串形式理论上也可行) 写上面那些东西的目的在证明依目前圣殿现有的系统架构，就可以 实现变动式地图资料及地图分享，而不需从 tmi2_v3_改 调用。 (当然，我会把它局限在只能使用於艾恩葛朗特) laechan --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.224.52.60 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/mud_sanc/M.1463624170.A.AC6.html