先谢谢你的回应，我澄清一下，我并没有反对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.绝大部份的物件都只是“摆在那里”，平常根本没作用，但是就
: 因此占用了一个物件位置，越看越烦
了解