這東西我在 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