在调试某套互动系统的过程中,测试账号经常需要频繁加房卡,而后台系统又没写这个功能,或者压根还没接通。为了省事,我就直接走数据库操作的方式,手动改一下房卡数量。 其实这操作说难也不难,关键是你得知道房卡的数量是存在哪张表、哪个字段。 房卡数据通常是保存在 QPTreasureDB 数据库下的 GameScoreInfo 表中。这个表记录的是每个用户的游戏资产,其中有一个字段叫 InsureScore,这个字段在大多数组件里就代表了“房卡数量”或“保险箱余额”。 打开数据库管理工具(比如 SQL Server Management Studio),依次展开: QPTreasureDB → 表 → dbo.GameScoreInfo 然后右键点开“编辑前200行”或者直接用 SELECT * FROM dbo.GameScoreInfo 查出所有记录。 你会看到如下字段: UserID: 用户编号 Score: 当前身上携带的资产 InsureScore: 房卡数量(重点) 其他诸如 WinCount, LostCount 之类的对局记录 如果你要修改某个用户的房卡数量,比如给 UserID = 1001 的用户设置成 50 张,可以直接执行以下 SQL: update GameScoreInfo set InsureScore = 50 where UserID = 1001 如果只是想简单加个 10 张,可以这么写: update GameScoreInfo set InsureScore = InsureScore + 10 where UserID = 1001 改完之后,重新登录客户端即可看到更新后的数量。 有时候你用客户端加房卡但没到账,或者服务端写入失败,也可以来这里核实到底有没有入库。 顺便提醒几句: 动数据库前先备份,特别是正式服,不然你手一抖多扣了几个 0,那可是实打实的玩家数据。 不要随便删行,这表里除了房卡,还有其他统计信息,哪怕字段是 0,也建议保留,系统有可能依赖它。 建议定期导出该表数据,比如做个“每日凌晨备份”,改数据之前心里也更踏实。 这类直接操作数据库的方法虽然方便,但终究只是权宜之计,建议有空还是补一套后台GM功能,把房卡增减操作通过权限控制起来,避免后期手动失控。 仅限技术交流,禁止商用!
在调试某套互动系统的过程中,测试账号经常需要频繁加房卡,而后台系统又没写这个功能,或者压根还没接通。为了省事,我就直接走数据库操作的方式,手动改一下房卡数量。 其实这操作说难也不难,关键是你得知道房卡的数量是存在哪张表、哪个字段。 房卡数据通常是保存在 QPTreasureDB 数据库下的 GameScoreInfo 表中。这个表记录的是每个用户的游戏资产,其中有一个字段叫 InsureScore,这个字段在大多数组件里就代表了“房卡数量”或“保险箱余额”。 打开数据库管理工具(比如 SQL Server Management Studio),依次展开: QPTreasureDB → 表 → dbo.GameScoreInfo 然后右键点开“编辑前200行”或者直接用 SELECT * FROM dbo.GameScoreInfo 查出所有记录。 你会看到如下字段: UserID: 用户编号 Score: 当前身上携带的资产 InsureScore: 房卡数量(重点) 其他诸如 WinCount, LostCount 之类的对局记录 如果你要修改某个用户的房卡数量,比如给 UserID = 1001 的用户设置成 50 张,可以直接执行以下 SQL: update GameScoreInfo set InsureScore = 50 where UserID = 1001 如果只是想简单加个 10 张,可以这么写: update GameScoreInfo set InsureScore = InsureScore + 10 where UserID = 1001 改完之后,重新登录客户端即可看到更新后的数量。 有时候你用客户端加房卡但没到账,或者服务端写入失败,也可以来这里核实到底有没有入库。 顺便提醒几句: 动数据库前先备份,特别是正式服,不然你手一抖多扣了几个 0,那可是实打实的玩家数据。 不要随便删行,这表里除了房卡,还有其他统计信息,哪怕字段是 0,也建议保留,系统有可能依赖它。 建议定期导出该表数据,比如做个“每日凌晨备份”,改数据之前心里也更踏实。 这类直接操作数据库的方法虽然方便,但终究只是权宜之计,建议有空还是补一套后台GM功能,把房卡增减操作通过权限控制起来,避免后期手动失控。 仅限技术交流,禁止商用!