这东西我在 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