先謝謝你的回應，我澄清一下，我並沒有反對wear或是虛擬物件
的系統，因為我根本沒有實際用過，也不是很懂。
恕刪
※ 引述《laechan (小太保)》之銘言：
: 很多東西是基於 sanc 的經驗，以虛擬物品系統為例，傳統的
: 很多我為 tmi2_v3_改 加入的新東西，都是基於類似的出發點
那我建議要明確告知使用者這一點，像我在研究DS Mudlib就知道
哪些遊戲是實作DS Mudlib的完成品，我可以從中學習各指令使用，
許多Mudlib裡面verb的定義是完全不同的(例:wear)。
: ，例如其中一個是「根據 sanc 的發展經驗」，sanc 是based
: on tmi2 mudlib 且已發展近 15 年的 mud，tmi2_v3_改 同樣
: 也是 based on tmi2 mudlib，因此我會執著地認為，有些東西
: 與其等使用者日後才發現「啊..當初應該要這麼做」，那還不
: 如我先把這些東西先寫出來塞進 tmi2_v3_改 裡頭。
: 但是使用者不一定要用這些東西，而我也不認為使用者要無視
: 這些東西的存在是一件很困難的事。
了解您的意思，讀完DS MudLib原文Q&A，裡面也有描述很多這方面的情況。
但我只能說，我讀了應該有100頁文件，我打開lib還是覺得WTF，
畢竟許多物件引用(例:inherit LIB_DOOR)是要先了解其用法。
: 這部份是我最弱的地方，但我會盡量把 document 寫完整一點。
: 我自己本身對 sanc 的相關 document 根本也沒怎麼看，而且我
: 也很懶，但即便如此，我最後還是大改了 sanc，所以我比較重視
: 這一塊，「就算有人跟我一樣懶，他還是可以拿 tmi2_v3_改 架
: 出 mud」，我想努力確保這種可能性。
: 我自己則證明了即便我沒怎麼看 tmi2 原生的一些 document 我
: 還是能介入核心的修改，並盡量將這些歷程紀錄起來於修改日誌
: 裡，就是希望讓大家知道「我是怎麼做到的」。
: 而且與其啃文件不如實際來問我比較快，比方在 mud 板或者是
: mud_sanc 板發問，我有看到就會回，回文的同時就留下紀錄了，
: 日後根據這些紀錄寫成的文件，至少也會比較易讀易懂一點。
: 光是看我在 tmi2_v3_改 的修改上所寫的一些文件，就可以瞭解
: 我寫 document 並不是照著正規的做法在寫的。
以DS Q&A 的描述是:
"What I want you to understand is that when I tell you to RTFM,
(註 Read the fucking manual)
I'm *not* giving you the brush-off because I like it. I'm
doing it because to you it's one little question. To me, it's
Creator FAQ #X, which I've answered 24 times before, and for
which I sat down and wrote out an excruciatingly detailed
explanation."
基本上就是讓你不要一直被雞毛蒜皮的小事打擾而己。
舉個例好了，我想做的MUD最終型希望玩家是帶領一個NPC隊伍探險
(這是我的個人喜好，先不論有沒有人要玩這種東西)
在研究文件時，我看完組隊，裝備型物件等等...
我可以有個基本的了解，例:與其使用force follow的指令使NPC移動
造成MUD可讀性下降，我考慮將NPC在equip時，轉化成類似裝備的物件
雖然我並沒有實作(短期也不可能動這個部份)，
至少，我讀完文件不會直接問你" 請問如何實作它 "
我上面只是舉例，請不要嘲笑我的外行想法。
: 以我最近寫的 simul intermud 為例，我是先寫了，然後我想說去
: 搜一下相關資料，才發現原來人家早就提出類似的想法(不是做法)
: 1.一樣是先找可信任的站當做 server 端
: 2.跟 server 端註冊，並 follow 其協定
: 3.這樣就能遠端頻道互連
intermud 我剛爬一下國外資料 TMI2和DS都有實作了，
我的DS mud一開就會看到國外大神們的聊天，文件有寫他們的做法，
但是我當然完全看不懂啦，不過其實短期內只要能用就好
: 1.總是會有遺失的困擾
: 2.發展到後期物件存在於各自的目錄，造成管理困擾
: 3.寫物件很煩人，對位階越大幹得越久的 adm/imm 越會如此
: 4.絕大部份的物件都只是「擺在那裡」，平常根本沒作用，但是就
: 因此佔用了一個物件位置，越看越煩
了解