嘛，很適合拿來動動腦。
簡單的說，因為不希望再增加防具部位了，所以想設計成玩家
直接帶在身上就會有效果，但是因實體物品會佔用儲存空間，
所以「不寫成實體物件」是確定的原則。
不是實體的，那就是虛擬的，判斷上來說:
if(user->query_vobjs("物品代碼")>0)
這樣就能判斷玩家是否攜帶該物品。
那麼首先會面臨的問題是：如何控管這類的判斷？
目前想到的做法是限縮這類物品的「代碼字頭」使用，例如以
目前的生命水晶使用 s 字頭為例，「這類物品」就只能使用
s 字頭，接著再限縮判斷方式為上面的那行程式。
這樣以後要找有寫這類判斷的系統物件時會容易一點。
更準確地說：只有系統物件會用到這類的判斷時才把這些物品
　　　　　　放在 s 字頭。不寫進系統物件的判斷就不要用.
再來就是效果問題，我目前有想到的只有「水晶」類，我預估
最多不超過十種，佔用 s001～s010 欄位，每一種水晶都有它
的用途，玩家身上可帶複數水晶，然後都可跟柯隆塔換。
(此時只有一種