v8 重构计划

[phoenixlzx]

功能

• 命令接口
  • 用户命令
  • 管理员命令
  • 消息互动命令
• 语言文件
• 全球市场（天喵）
  • 天喵
  • 上架费用
  • 物品有效期：有效期后自动下架保存在临时存储，每 24h 收取价格 % 的保管费用直到玩家取回
• 木牌商店（玩家/系统）
  • 收购
  • 出售
  • 乐透
• 展示框商店
  • 用作卖出
  • 设置后展示店内随机物品，每个物品只能在一个展示框里展示。如果是堆叠物品，一次交易只购买一个，且原物品不消失（可继续购买）。另购买时需确认该物品是否仍有库存
  • 两次点击确认交易取出物品
  • 只能在合理位置设置展示框
• 拍卖/征购
  • 玩家拍卖/征购
  • 拥有权限的管理员以系统身份拍卖/征购
  • 系统自动拍卖/征购
• 担保交易（天喵直送，可配置交易等待时间，超时自动取消）
• 系统余额（HEH 内置 / Vault 账户）
• 税务
• 搜索
  • 搜索所有天喵和木牌商店中的物品，包括材料、名称、lore 和附魔
  • 搜索需要同时展示商店位置信息（天喵、木牌坐标等）
• 管理工具
  • 所有在任意途径出售的物品都有 UID
  • 删除特定玩家的所有木牌信息
  • 删除特定玩家的特定物品/所有物品
• API
• 性能问题（主要是天喵，NBT 相关

广告功能并没有人用所以不要了。

配置

config.yml

language: en_US
balance:
  base: 10000 # system balance base, used in automation.
  vault: SYSTEM # SYSTEM = use HEH system balance, 'player' value is ignored. PLAYER = use player vault account.
  player: 073f34981d8043bb962757e7a4989c1c # player UUID
tax:
  market: 10
  signshop: 5
  direct: 5
  auction: 20
  requisition: 5
fee:
  market:
    base: 100
    storage: 10
  signshop:
    base: 0
  direct:
    base: 50
  auction:
    base: 100
  requisition:
    base: 50
limits:
  slots:
    market: 5
    signshop: 100
  signs: 3
  frames: 12

automation.yml - 自动化用配置，暂不开发

命令

所有命令默认权限都是 op，需要手动赋予玩家组。

Command	Permission	Desc
/h [m|market]	heh.business.market	打开商城
/h [m|market] <unit price>	heh.business.market	上架到天喵 / 购买物品
/h shop [sell|buy] [unit price]	heh.business.signshop	使用木牌商店
/h chest req	heh.business.chest.req	指定收购箱子
/h chest lotto	heh.business.chest.lotto	指定 lotto 箱子
/h auc [base] [step] <reserve>	heh.business.auction	拍卖
/h req [material|HAND] [unit price] [amount] <additional params...>	heh.business.requisition	收购
/h bid <price>	heh.business.bid	出价到当前拍卖，如无 price 参数则出最低加价
/h sell <amount>	heh.business.sell	出售到当前征购
/h sellto [player] [unit price]	heh.business.sellto	直接出售给特定玩家
/h pay [invoice id]	heh.business.pay	支付账单
/h cancel [invoice id]	heh.business.cancel	取消账单
/h frame	heh.business.frame	设置物品展示框
/h storage	heh.storage	打开临时存储（只能取回）
/h search <params...>	heh.search	搜索
/heh balance [view|pay|take] <params...>	heh.admin.balance	管理系统余额
/heh remove [item|shop|player|storage] [item id|player name|sign]	heh.admin.remove	移除特定物品/玩家数据/木牌或展示框等商店实体
/heh run auc|req <params...>	heh.admin.run	以系统身份执行拍卖/征购

[ReinWD]

目前的数据库工具类实现目前讨论的结构理论上可以，但是可能会出现潜在的性能问题/数据冗余存储的问题

性能问题

用uuid作为索引性能会低于直接使用数字id->player

以co存储方式为例，存储玩家信息使用的是一个数字id，int，这个int对应了一个uuid和一个玩家名，大量重复的uuid不需要被存储
索引查找时也不需要匹配字符串而是匹配数字
我想法是利用这个特性来减小交易记录的存储量与signshop、market的存储量

耦合性问题

现有架构一个item表解决所有的signshop、market、Lottle的对应关系还可能带来一个耦合性高的问题
日后想扩展（比如加个功能）可能会遇到麻烦
数据表结构定下之后想改基本只能再次重构。。。

想法

如果想解决的话要用到inner操作，目前NC对数据库操作做不到，需要造个轮子解决inner操作的问题。
可以暂时使用多次查询方式临时解决问题之后再从内部把操作重构（也就是可以先糊功能再解决性能问题）

以signshop为例，设计的存储架构如下

位置和owner信息存成这样

signshop_meta

|id|owner|world_x|……|

实际内部的道具存成这样

signshop_items

|id|signshop_id|item_id|
|int|int|int|

使用signshop_id和item_id分别先筛出需要的记录再把具体值套上去
这样做索引大概会快非常多，而且省空间

item存成这样
item

|id|nbt|unit_price|……|
|int|int|int|……|

nbt

|id|nbt|
|int|TEXT|

交易记录也可查询到对应的item的实时状态

坏处也有。。就是交易记录不好和主要功能分开了，可以进行定期挪出非活跃物品至另一数据表内永久保存，这个功能可以后期加

[RecursiveG]

数据库主要问题有两个。一个是不同DBMS(e.g. SQLite vs MySQL)有各自的SQL方言（主要是数据类型和autoincrement (对我就是在说你sqlite)），导致NC实现的复杂度增加，建议固定一个数据库。二是没有DBA，导致每次更新/重构都引入schema上的变动就GG。另外不建议把NC的数据库组件扩展成支持inner，要么直接SQL，要么抛弃NC的数据库换成一个有维护的功能全的。自己写太容易出错了。更别提多线程+事务混着用的情况了。