简介围绕《Metin2》游戏中的时装武器Costume Weapon与本地化内容这套资源适合希望研究客户端/服务端实现、进行二创或私服定制的玩家与开发者。压缩包共21个文件总大小23KB以C代码为主内含11个cpp源文件、7个h头文件以及2个txt文本与1个python脚本覆盖时装武器窗口UI逻辑、物品原型解析、数据库读取等典型模块可用于梳理时装武器的加载与注册流程也可作为理解游戏本地化数据结构的参考。已有232人学习浏览。解压后可见客户端与服务端分离的目录结构txt文件通常充当说明或配置线索py脚本能辅助处理proto、dump等数据资源结合代码中的类型定义与字段映射可快速定位时装武器从服务端下发到客户端展示的关键链路并据此调整外观、属性或本地化文本从而完善Metin2修改方案。1. 时装武器不是套个模型那么简单Metin2 的时装武器在玩家眼里只是换个外观在源码层面却是一套横跨客户端与服务端的数据契约同一件时装武器要同时出现在 item_proto 文本、服务端 common 的类型枚举、db 数据库和客户端的 Python 界面里。这个压缩包把 client 侧的 gamelib、UserInterface服务端的 common/db/game 按目录分好核心是 item_proto、typok.txt、ItemCSVReader.cpp、costumewindow.py 这条从文本到界面的解析链还带了一个匈牙利语写的 OLVASD EL务必阅读说明。哪些文件放哪一侧、装完怎么验证下面逐层拆。2. 客户端先立住item_proto、typok.txt 与 ItemCSVReader 的解析链包里的 OLVASD EL 文件用匈牙利语写清楚了目录归属kliens oldal 指 Client 侧szerver oldal 指 Server 侧。客户端这一半的链路相对固定从 item_proto 文本出发经过 typok.txt 的类型映射由 ItemCSVReader.cpp 读进内存最后被 Python UI 消费。任何一个环节漏改时装的显示层都会出问题。2.1 item_proto 的列结构与时装武器行客户端所有物品的最初来源是根目录的 item_proto.txt纯文本、按空格分隔、一行一件物品。Vnum物品 ID、名称Name、类型Type、子类型Subtype之后跟着一大串 0/1 标记和属性列。时装武器行最常犯错的地方有两处。第一处是 Type/Subtype 组合。时装武器要挂在 ITEM_TYPE_COSTUME 大类下子类型用 COSTUME_WEAPON如果沿用普通武器的 type 值客户端会把外观属性当成真实攻击力参与战斗结算违背只换外观不动属性的设计。第二处是 WearFlags 必须带上穿戴位常见分支里是 WEAR_COSTUME否则客户端不认这个槽位装备后切地图时会被服务端弹回背包。列段代表字段时装武器的常见填法0Vnum独立大号段避免与官方物品冲突1Name唯一的英文 key显示名另走 custumelocale 本地化映射2-3Type / SubtypeITEM_TYPE_COSTUME / COSTUME_WEAPON4-5尺寸与堆叠1x1堆叠数为 16WearFlags保留原武器位并加上 WEAR_COSTUME 位7属性列全部置 0武器数值不在这里给把新加的时装武器行和官方普通武器行并排看最直观的差别就是属性列是干净的只有类型和穿戴位长得像武器。2.2 typok.txt 把数字类型变成 UI 能读的名字typok.txt 是客户端本地的一张类型名映射表负责把 item_proto 里的纯数字 type/subtype 转成可读字符串。物品 tooltip 的分类、背包排序、拍卖行过滤都走这张表。新加了时装武器类型却不动这个文件通常不会立刻报错而是表现为 UI 把物品归为未知。# typok.txt 常见格式父类型 子类型 可读名称 17 0 ITEM_TYPE_COSTUME 17 2 COSTUME_WEAPON第一列是物品大类第二列是子类型第三列是客户端内部使用的名字与 proto 列号没有关系改它不影响数值解析。这个文件只影响客户端显示与分类不需要同步到服务端但要跟着 item_proto 一起打进客户端资源包只改本地文件不重新打包的话正式端里仍然读不到新映射。2.3 ItemCSVReader.cpp 的解析与容错ItemCSVReader.cpp 是客户端真正读 item_proto 的解析器。它的逻辑不复杂按行切分、按列取整、填进 ItemData 缓存表。真正容易出问题的是字段序不同分支的 proto 列数不一样解析器写死了一个列号服务端生成的 proto 列序和它对不上就会出现客户端读出来的 Item 全是 0这类静默错误。// ItemCSVReader.cpp 典型解析片段按列号取值 const char* tok GetToken(line, col); if (col 2) item-type atoi(tok); // 物品大类 else if (col 3) item-subtype atoi(tok); // 物品子类 else if (col 6) item-wearable atoi(tok);// 穿戴位标记 else if (col 8) { // 属性区起点 if (col - 8 ITEM_VALUES_MAX) item-values[col - 8] atoi(tok); }这段代码想说明两件事。其一解析是全量顺序推进的在属性区中间新增一列而不改基准列号会导致后面所有字段错位其二values 数组下标由 col 减去属性起始列得到服务端在 proto 里插列时这个 8 的偏移量也要跟着改。我加时装武器时习惯在 proto 末尾追加属性列而不是中间插列就是为了不动这个偏移量也让 Dump Proto 出来的文本左右对比时更容易看清差异。3. 服务端三层联动common 定协议、db 存数据、game 管穿戴服务端不是把 item_proto 再读一遍就完事它要在编译期就知道什么物品能穿、穿上去算什么。做了多年 Metin2 相关改动的同行应该都有共识时装武器这类跨层功能九成故障出在某一层改了、另一层还在用旧值。3.1 common 的类型枚举是双方协议的锚点双方共识写在 common 目录的 item 相关头文件里客户端和服务端编译时共用这份枚举。任何一侧改了常量数值、另一侧没同步穿戴判断就会错位。// server/common/item.h 的典型分支写法 enum ItemType { ITEM_TYPE_WEAPON 0, ITEM_TYPE_ARMOR 1, ITEM_TYPE_COSTUME 17, // 时装大类客户端必须一致 }; enum CostumeSubType { COSTUME_BODY 0, COSTUME_HAIR 1, COSTUME_WEAPON 2, // 时装武器子类型 };先把枚举对齐再谈功能。我见过不止一次服务端用 ITEM_TYPE_COSTUME 17客户端源码里却是 18结果服务端穿戴成功、客户端显示成空槽。两边的 item 头文件 diff 一下通常几秒钟就能定位。3.2 db 层item_proto 落库与角色时装栏db 目录承担两件事。第一把 item_proto 表灌进数据库服务端实际查的是数据库里的物品定义而不是直接读文本第二角色时装槽位的存档。时装栏在多数分支里是独立一张表最小字段如下。-- 角色时装栏的最小表结构按分支可扩展 socket、attr 列 CREATE TABLE IF NOT EXISTS player_costume ( pid INT NOT NULL, slot TINYINT NOT NULL, item_vnum INT NOT NULL, count TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (pid, slot) );这里有个先后顺序问题表结构要等 proto 里的 vnum 定了之后再建立否则灌数据时外键或校验逻辑会报错。如果你用 Dump Proto 工具导出了一份客户端 proto先把导出的文本和数据库 item_proto 表做一次 vnum 差集多出来的行就是两侧没对齐的物品。db 层对象职责时装武器改动的落点item_proto 表物品静态定义按 vnum 新增一行player_costume 表角色时装槽存档穿戴时 upsert 槽位记录操作日志表排错依据观察穿戴请求是否到达 db3.3 game 层穿戴时的属性剥离与存档game 目录是实际穿戴逻辑所在。时装武器的核心原则是外观生效、属性不动所以在穿戴入口处要把普通武器的攻击力计算分支拦下来只更新外观标记再写入角色存档。// game 侧穿戴时装武器的判断伪代码 if (item-GetType() ITEM_TYPE_COSTUME item-GetSubType() COSTUME_WEAPON) { if (!IsCostumeWeaponUsable(item)) return false; // 不叠加攻击力/攻速只写外观状态 ch-SetCostumeWeapon(item-GetVnum()); ch-UpdatePacket(); // 向周围玩家广播外观变化 return true; }这里有个常见坑有些分支的 UpdatePacket 会把普通武器模型一起带出去别人看你的角色时时装武器和真实武器叠在一起。处理办法是把外观模型走独立的 ChangeLook 通道只同步 vnum 到客户端渲染层。存档则在断开连接或定时保存时把 vnum 写回 player_costume 表SQL 用不存在则插入、存在则更新的 upsert 写法否则角色第一次穿时装会丢记录。4. costumewindow.py把时装槽位接到客户端界面costumewindow.py 是 UserInterface 下的 Python 窗口负责显示角色时装栏里的武器外观。理解这个文件的关键是它本身不持有物品数据所有槽位内容都来自 C 侧 Player 对象注入的快照Python 侧只做渲染和响应。4.1 窗口脚本与 C 侧的绑定# costumewindow.py 的核心结构常见客户端 UI 写法 import uiWindow class CostumeWindow(uiWindow.Window): def __init__(self, main): uiWindow.Window.__init__(self, main) self.costumeSlots {} # slot - [vnum, count] self.weaponPreview None # 展示用时装武器 def RefreshCostume(self, itemList): # itemList 由 C 侧在窗口打开/穿戴变化时传入 for slot, (vnum, count) in itemList.items(): self.costumeSlots[slot] (vnum, count) self._UpdateSlotIcon(slot, vnum) def _UpdateSlotIcon(self, slot, vnum): # 按 vnum 查 item proto 取图标资源 iconPath self.GetItemIconPath(vnum) self.costumeSlots[slot].SetIcon(iconPath)RefreshCostume 的入参是一个 slot - (vnum, count) 的字典其中 vnum 决定图标和提示信息count 决定是否要渲染数量角标。图标路径要从 proto 的资源字段读而不是自己拼文件名否则新增模型时就得改 Python 源码。C 侧负责保证传入顺序稳定Python 侧不要自己跨层去读背包结构。触发时机调用入口刷新粒度角色上线RefreshCostume(全量列表)所有时装槽打开窗口RefreshCostume(当前栏)对齐背包显示穿戴/卸下回包RefreshCostume(单槽)只更新对应槽位4.2 穿戴刷新的触发时机与网络包玩家点穿戴后请求包发到服务端服务端校验通过回包C 侧再回调 RefreshCostume 刷新界面。最容易出问题的是回包顺序服务端先广播外观更新、后回 UI 刷新包时客户端会先重绘角色再刷新窗口表现为窗口图标正确、角色模型短暂显示旧外观。常见做法是把角色外观重绘和窗口刷新串成一条链先让 C 侧把换装动画播完再回调 Python 更新槽位。具体到代码可以在换装动画结束事件里挂刷新函数或者给 RefreshCostume 加一个延迟调用。另一个值得注意的点是窗口脚本不要直接操作 inventory 层的数据结构跨层改数据在切场景时会和 C 侧的内存释放撞车表现就是随机闪断这类问题最难查。5. 验证清单proto 不同步时的三种典型炸法装完一套时装武器别急着开服先做三个最小验证。第一种客户端拿不到物品游戏里刷出物品背包出现但图标空白。先查 item_proto 的 vnum 是否在客户端 proto、服务端内存表、数据库 item 表三处都存在通常缺的是数据库那张表。用 Dump Proto 把服务端 proto 导出和客户端 proto 做 vnum 差集很快能定位。第二种装备上就闪断客户端和服务端的枚举值不一致比如 ITEM_TYPE_COSTUME 一边是 17 一边是 18。服务端认为穿戴成功客户端按自己的枚举解析不出来协议对不上直接断线。处理方法是对比两个工程里的 item 头文件数值逐个对齐重新编译客户端再打包。第三种外观正常但属性异常时装武器要么增强了攻击力要么干脆没模型。前者说明属性列被填了值清零即可后者说明模型资源没进客户端打包资源或者 proto 里的模型字段指向了不存在的文件名把路径指向时装专用的模型文件即可。最后给一个实用技巧把 proto 校验做成启动时对比 vnum 数量。服务端启动和客户端登录时分别统计 proto 行数并输出到日志两个数字对不上立即报警比等人反馈装备不见了要省力得多。本文还有配套的精品资源点击获取
Metin2时装武器从proto到UI的完整解析链与排错指南
简介围绕《Metin2》游戏中的时装武器Costume Weapon与本地化内容这套资源适合希望研究客户端/服务端实现、进行二创或私服定制的玩家与开发者。压缩包共21个文件总大小23KB以C代码为主内含11个cpp源文件、7个h头文件以及2个txt文本与1个python脚本覆盖时装武器窗口UI逻辑、物品原型解析、数据库读取等典型模块可用于梳理时装武器的加载与注册流程也可作为理解游戏本地化数据结构的参考。已有232人学习浏览。解压后可见客户端与服务端分离的目录结构txt文件通常充当说明或配置线索py脚本能辅助处理proto、dump等数据资源结合代码中的类型定义与字段映射可快速定位时装武器从服务端下发到客户端展示的关键链路并据此调整外观、属性或本地化文本从而完善Metin2修改方案。1. 时装武器不是套个模型那么简单Metin2 的时装武器在玩家眼里只是换个外观在源码层面却是一套横跨客户端与服务端的数据契约同一件时装武器要同时出现在 item_proto 文本、服务端 common 的类型枚举、db 数据库和客户端的 Python 界面里。这个压缩包把 client 侧的 gamelib、UserInterface服务端的 common/db/game 按目录分好核心是 item_proto、typok.txt、ItemCSVReader.cpp、costumewindow.py 这条从文本到界面的解析链还带了一个匈牙利语写的 OLVASD EL务必阅读说明。哪些文件放哪一侧、装完怎么验证下面逐层拆。2. 客户端先立住item_proto、typok.txt 与 ItemCSVReader 的解析链包里的 OLVASD EL 文件用匈牙利语写清楚了目录归属kliens oldal 指 Client 侧szerver oldal 指 Server 侧。客户端这一半的链路相对固定从 item_proto 文本出发经过 typok.txt 的类型映射由 ItemCSVReader.cpp 读进内存最后被 Python UI 消费。任何一个环节漏改时装的显示层都会出问题。2.1 item_proto 的列结构与时装武器行客户端所有物品的最初来源是根目录的 item_proto.txt纯文本、按空格分隔、一行一件物品。Vnum物品 ID、名称Name、类型Type、子类型Subtype之后跟着一大串 0/1 标记和属性列。时装武器行最常犯错的地方有两处。第一处是 Type/Subtype 组合。时装武器要挂在 ITEM_TYPE_COSTUME 大类下子类型用 COSTUME_WEAPON如果沿用普通武器的 type 值客户端会把外观属性当成真实攻击力参与战斗结算违背只换外观不动属性的设计。第二处是 WearFlags 必须带上穿戴位常见分支里是 WEAR_COSTUME否则客户端不认这个槽位装备后切地图时会被服务端弹回背包。列段代表字段时装武器的常见填法0Vnum独立大号段避免与官方物品冲突1Name唯一的英文 key显示名另走 custumelocale 本地化映射2-3Type / SubtypeITEM_TYPE_COSTUME / COSTUME_WEAPON4-5尺寸与堆叠1x1堆叠数为 16WearFlags保留原武器位并加上 WEAR_COSTUME 位7属性列全部置 0武器数值不在这里给把新加的时装武器行和官方普通武器行并排看最直观的差别就是属性列是干净的只有类型和穿戴位长得像武器。2.2 typok.txt 把数字类型变成 UI 能读的名字typok.txt 是客户端本地的一张类型名映射表负责把 item_proto 里的纯数字 type/subtype 转成可读字符串。物品 tooltip 的分类、背包排序、拍卖行过滤都走这张表。新加了时装武器类型却不动这个文件通常不会立刻报错而是表现为 UI 把物品归为未知。# typok.txt 常见格式父类型 子类型 可读名称 17 0 ITEM_TYPE_COSTUME 17 2 COSTUME_WEAPON第一列是物品大类第二列是子类型第三列是客户端内部使用的名字与 proto 列号没有关系改它不影响数值解析。这个文件只影响客户端显示与分类不需要同步到服务端但要跟着 item_proto 一起打进客户端资源包只改本地文件不重新打包的话正式端里仍然读不到新映射。2.3 ItemCSVReader.cpp 的解析与容错ItemCSVReader.cpp 是客户端真正读 item_proto 的解析器。它的逻辑不复杂按行切分、按列取整、填进 ItemData 缓存表。真正容易出问题的是字段序不同分支的 proto 列数不一样解析器写死了一个列号服务端生成的 proto 列序和它对不上就会出现客户端读出来的 Item 全是 0这类静默错误。// ItemCSVReader.cpp 典型解析片段按列号取值 const char* tok GetToken(line, col); if (col 2) item-type atoi(tok); // 物品大类 else if (col 3) item-subtype atoi(tok); // 物品子类 else if (col 6) item-wearable atoi(tok);// 穿戴位标记 else if (col 8) { // 属性区起点 if (col - 8 ITEM_VALUES_MAX) item-values[col - 8] atoi(tok); }这段代码想说明两件事。其一解析是全量顺序推进的在属性区中间新增一列而不改基准列号会导致后面所有字段错位其二values 数组下标由 col 减去属性起始列得到服务端在 proto 里插列时这个 8 的偏移量也要跟着改。我加时装武器时习惯在 proto 末尾追加属性列而不是中间插列就是为了不动这个偏移量也让 Dump Proto 出来的文本左右对比时更容易看清差异。3. 服务端三层联动common 定协议、db 存数据、game 管穿戴服务端不是把 item_proto 再读一遍就完事它要在编译期就知道什么物品能穿、穿上去算什么。做了多年 Metin2 相关改动的同行应该都有共识时装武器这类跨层功能九成故障出在某一层改了、另一层还在用旧值。3.1 common 的类型枚举是双方协议的锚点双方共识写在 common 目录的 item 相关头文件里客户端和服务端编译时共用这份枚举。任何一侧改了常量数值、另一侧没同步穿戴判断就会错位。// server/common/item.h 的典型分支写法 enum ItemType { ITEM_TYPE_WEAPON 0, ITEM_TYPE_ARMOR 1, ITEM_TYPE_COSTUME 17, // 时装大类客户端必须一致 }; enum CostumeSubType { COSTUME_BODY 0, COSTUME_HAIR 1, COSTUME_WEAPON 2, // 时装武器子类型 };先把枚举对齐再谈功能。我见过不止一次服务端用 ITEM_TYPE_COSTUME 17客户端源码里却是 18结果服务端穿戴成功、客户端显示成空槽。两边的 item 头文件 diff 一下通常几秒钟就能定位。3.2 db 层item_proto 落库与角色时装栏db 目录承担两件事。第一把 item_proto 表灌进数据库服务端实际查的是数据库里的物品定义而不是直接读文本第二角色时装槽位的存档。时装栏在多数分支里是独立一张表最小字段如下。-- 角色时装栏的最小表结构按分支可扩展 socket、attr 列 CREATE TABLE IF NOT EXISTS player_costume ( pid INT NOT NULL, slot TINYINT NOT NULL, item_vnum INT NOT NULL, count TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (pid, slot) );这里有个先后顺序问题表结构要等 proto 里的 vnum 定了之后再建立否则灌数据时外键或校验逻辑会报错。如果你用 Dump Proto 工具导出了一份客户端 proto先把导出的文本和数据库 item_proto 表做一次 vnum 差集多出来的行就是两侧没对齐的物品。db 层对象职责时装武器改动的落点item_proto 表物品静态定义按 vnum 新增一行player_costume 表角色时装槽存档穿戴时 upsert 槽位记录操作日志表排错依据观察穿戴请求是否到达 db3.3 game 层穿戴时的属性剥离与存档game 目录是实际穿戴逻辑所在。时装武器的核心原则是外观生效、属性不动所以在穿戴入口处要把普通武器的攻击力计算分支拦下来只更新外观标记再写入角色存档。// game 侧穿戴时装武器的判断伪代码 if (item-GetType() ITEM_TYPE_COSTUME item-GetSubType() COSTUME_WEAPON) { if (!IsCostumeWeaponUsable(item)) return false; // 不叠加攻击力/攻速只写外观状态 ch-SetCostumeWeapon(item-GetVnum()); ch-UpdatePacket(); // 向周围玩家广播外观变化 return true; }这里有个常见坑有些分支的 UpdatePacket 会把普通武器模型一起带出去别人看你的角色时时装武器和真实武器叠在一起。处理办法是把外观模型走独立的 ChangeLook 通道只同步 vnum 到客户端渲染层。存档则在断开连接或定时保存时把 vnum 写回 player_costume 表SQL 用不存在则插入、存在则更新的 upsert 写法否则角色第一次穿时装会丢记录。4. costumewindow.py把时装槽位接到客户端界面costumewindow.py 是 UserInterface 下的 Python 窗口负责显示角色时装栏里的武器外观。理解这个文件的关键是它本身不持有物品数据所有槽位内容都来自 C 侧 Player 对象注入的快照Python 侧只做渲染和响应。4.1 窗口脚本与 C 侧的绑定# costumewindow.py 的核心结构常见客户端 UI 写法 import uiWindow class CostumeWindow(uiWindow.Window): def __init__(self, main): uiWindow.Window.__init__(self, main) self.costumeSlots {} # slot - [vnum, count] self.weaponPreview None # 展示用时装武器 def RefreshCostume(self, itemList): # itemList 由 C 侧在窗口打开/穿戴变化时传入 for slot, (vnum, count) in itemList.items(): self.costumeSlots[slot] (vnum, count) self._UpdateSlotIcon(slot, vnum) def _UpdateSlotIcon(self, slot, vnum): # 按 vnum 查 item proto 取图标资源 iconPath self.GetItemIconPath(vnum) self.costumeSlots[slot].SetIcon(iconPath)RefreshCostume 的入参是一个 slot - (vnum, count) 的字典其中 vnum 决定图标和提示信息count 决定是否要渲染数量角标。图标路径要从 proto 的资源字段读而不是自己拼文件名否则新增模型时就得改 Python 源码。C 侧负责保证传入顺序稳定Python 侧不要自己跨层去读背包结构。触发时机调用入口刷新粒度角色上线RefreshCostume(全量列表)所有时装槽打开窗口RefreshCostume(当前栏)对齐背包显示穿戴/卸下回包RefreshCostume(单槽)只更新对应槽位4.2 穿戴刷新的触发时机与网络包玩家点穿戴后请求包发到服务端服务端校验通过回包C 侧再回调 RefreshCostume 刷新界面。最容易出问题的是回包顺序服务端先广播外观更新、后回 UI 刷新包时客户端会先重绘角色再刷新窗口表现为窗口图标正确、角色模型短暂显示旧外观。常见做法是把角色外观重绘和窗口刷新串成一条链先让 C 侧把换装动画播完再回调 Python 更新槽位。具体到代码可以在换装动画结束事件里挂刷新函数或者给 RefreshCostume 加一个延迟调用。另一个值得注意的点是窗口脚本不要直接操作 inventory 层的数据结构跨层改数据在切场景时会和 C 侧的内存释放撞车表现就是随机闪断这类问题最难查。5. 验证清单proto 不同步时的三种典型炸法装完一套时装武器别急着开服先做三个最小验证。第一种客户端拿不到物品游戏里刷出物品背包出现但图标空白。先查 item_proto 的 vnum 是否在客户端 proto、服务端内存表、数据库 item 表三处都存在通常缺的是数据库那张表。用 Dump Proto 把服务端 proto 导出和客户端 proto 做 vnum 差集很快能定位。第二种装备上就闪断客户端和服务端的枚举值不一致比如 ITEM_TYPE_COSTUME 一边是 17 一边是 18。服务端认为穿戴成功客户端按自己的枚举解析不出来协议对不上直接断线。处理方法是对比两个工程里的 item 头文件数值逐个对齐重新编译客户端再打包。第三种外观正常但属性异常时装武器要么增强了攻击力要么干脆没模型。前者说明属性列被填了值清零即可后者说明模型资源没进客户端打包资源或者 proto 里的模型字段指向了不存在的文件名把路径指向时装专用的模型文件即可。最后给一个实用技巧把 proto 校验做成启动时对比 vnum 数量。服务端启动和客户端登录时分别统计 proto 行数并输出到日志两个数字对不上立即报警比等人反馈装备不见了要省力得多。本文还有配套的精品资源点击获取
