灌个水。(真物理灌水，咕噜咕噜...
sanc 还没真正实装这个东西，想说来研究看看，或许打着打着，
sanc 那边就给它实装了也说不定。
在部份 mud，玩家资料档的 obj_data 字段可以做如下储存:
obj_data ([
"/weapon/lodoos/sword1#123456":(["improve_lv":5, ...]),
.
.
])
也就是以物品的档名做为 key 值，后面接这个物品的额外储存资
料，当玩家 login 时，依照 key 值 clone_object 物品出来的
同时，再做以下的动作:
ob=clone_object(files);
foreach(str in keys(obj_data[files]))
ob->set(str,obj_data[files][str]);
例如把上述的 improve_lv 值 5 设定到该 clone_object 出来的
物品上面，再把该物品 move 到玩家身上。
这类关于额外储存的资料，需满足以下条件:
一、最少设定(储存)项目
二、最简设定(储存)原则
比方也有人是用 refine 做为精炼的意思，我个人的评估思维是，
如果指令敲起来好敲(refine蛮好敲的)，意思也有点儿到了，长度
没有很长....这里的长度指的是
refine_lv 精炼等级
refine_stat 精炼所提升的属性质
.
.
做为储存字段来说看起来还 ok，那我多半就会用了。
那首先就 refine_lv 即精炼等级来说，像 RO 可以精练到 1x 等
，而且是武器防具都可以，而且还有套装及插卡方面的设定，还会
有依精炼值做额外属性加成的设定，因此我会一并考虑精炼是否额
外储存 refine_stat 的问题。
我的思维是，假设做额外储存，那直觉上会有几个问题:
1.如果我改变精炼规则，我很难去更动之前已被玩家精炼的物品
2.若不存这个字段，我怎么解决加载时的 loading 问题
3.我将来要怎么去统一管理这些已经被精炼的物品的refine_stat
储存值
1 的部份就是说，比方我原先订 +1 就是该武防各属性 +5，那后来
我觉得 +5 太多了想改 +3 时，玩家之前已精炼的东西我就得做额
外的处理(把那些 +5 改成 +3)。
而既然以后可能会有这个问题，那还不如在 loading 时就处理:
ob=clone_object(files);
foreach(str in keys(obj_data[files]))
{
ob->set(str,obj_data[files][str]);
switch(str)
{
case "refine_lv":
lv=obj_data[files][str];
ob->set("refine_stat",lv*5);
.
.
上面的意思就是说我只储存 refine_lv，而当玩家登入时，我再依该
物品的 refine_lv 值，来设定 refine_stat 的值是多少；玩家save
或是把该物品储放进仓库时，只存 refine_lv 不存 refine_stat，也
就是上述的最少设定(储存)项目，而上面的 switch..case.. 用来做
为额外的处理。
那么 coding 常遇到的情况就是
当我们储存的项目越多时 就可以减少很多额外的处理
当我们储存的项目很少时 就需要很多其它额外的处理
例如我们只单存一个 refine_lv 时，就可以想见在很多地方都需要先
读取出这个值，然后再做额外的运算来得到其它我们想要的东西，例
如 refine_stat、refine_name、.... 等等。
通常根据均值定理，可得出一个适当的储存项目数量，使得储存的项
目不至于过多，且不会增加很多需做的额外处理。
但是根据经验，其实还有另一种做法，就是 RO 所采取的额外描述法
例如 RO 的蛇披，它的 Special DEX 部份是这么说的
https://upload.8591.com.tw/ware/201905/1557133186868273AY.png
Dex+1
精炼值+8时Dex+3
当精炼值+9时MATK+1%
当精练值+12时ASPD+1，固定咏唱时间-7%
也就是说，玩家登入或从仓库拿出此物品时，只加载 refine_lv 的设
定值，但是当玩家做 wear 或 wield 时，才做以下的动作:
lv=ob->query("refine_lv");
switch(lv)
{
case 1..7: ob->add("stat/dex",1);
case 8 : ob->add("stat/dex",3);
.
.
}
而其它时候，比方玩家 view 该物品时，只会看到上面的“描述”，以
及该物品的精炼值，既然玩家只有在做 wear 及 wield 时，该精炼值才
会有作用，那自然只需在玩家 wear 及 wield 时做相关的处理就好。
我相信 RO 也是这样做的，所以它们才会规定物品在手持或穿戴时无法
精炼，必须先脱下来才行。
因此理论上，只储存 refine_lv 值应该是可以的。
而这可以带来几个好处:
一、refine_lv 这个储存字段的变动性不高，应该确定就是这个字段，
连同精炼指令也可以顺便定为 refine。
二、之后可以只先处理 wield/wear 指令，马上就能进行相关测试，例
如穿脱时的玩家属性变化、quit/login 时是否正常加载等。
三、再之后才是其它与观看该物品相关的指令，例如 inventory、look
、view、auc、.....等。
精炼名称的部份，最直觉是以下的显示:
+0时: 罗德斯长剑(lodoos sword)
+9时: +9罗德斯长剑(lodoos sword)
然后最优先考量是战斗时，是否希望+9出现:
你以手中的罗德斯长剑刺向小麻雀
你以手中的+9罗德斯长剑刺向小麻雀
看起来好像让 +9 出现也不错？当然这与各家 mud 风格有关且因人而
异。
其它的话问题就小一点，如果希望到处都能带 +9，那么在加载时就做
处理是比较好的:
foreach(str in keys(obj_data[files]))
{
ob->set(str,obj_data[files][str]);
switch(str)
{
case "refine_lv":
lv=obj_data[files][str];
if(lv>0)
{
shorts=ob->query("short");
ob->set("short",sprintf(HIG"+%d"NOR"%-s",lv,shorts));
.
.
这样它就到处带 +9 时，那万一玩家将 +9 精炼成 +10 呢，也很简单
因为它格式是固定的:
shorts=ob->query("short");
lv=ob->query("refine_lv");
shorts=replace_string(shorts,"+"+lv,"+"+(lv+1));
因为 +n 这个东西在物品的 short 只会出现在精炼识别名称区块，平
常不可能有精炼值为 0 的物品，其名称会带 +n 的，就容易做名称上
的取代。
有时间再打点别的回在下篇。