GT Wiki

外观

跨服与存储 ​

跨服组队必须先把单服流程跑通。创建队伍、邀请、公开房间、选择副本、体力扣除、单服启动都没问题后，再接 MySQL、Redis 和代理。

什么时候需要共享存储 ​

这些场景需要多个子服看到同一份数据：

  • 队长在 A 服，队员在 B 服。
  • 公开房间要跨服显示。
  • 邀请和申请要跨服处理。
  • 队伍成员所在服要显示。
  • 队长开始副本后，要把全队送到目标副本服。
  • 目标副本服要读取等待中的开本请求。

单服不用跨服时，storage.mode: local 就够。

存储选择 ​

yaml
storage:
  mode: auto
模式适合
local单服测试
mysql稳定持久化，适合正式网络
redis快速状态同步，适合跨服队伍和短期请求
auto有 Redis 用 Redis，有 MySQL 用 MySQL，否则 local

跨服网络里，所有子服必须写同一套 MySQL 或 Redis 配置。

MySQL 配置 ​

yaml
storage:
  mode: mysql

mysql:
  enabled: true
  host: 127.0.0.1
  port: 3306
  database: gtdungeonteam
  username: root
  password: ""
  params:
    useSSL: false
    serverTimezone: Asia/Shanghai
    characterEncoding: utf8
  pool:
    maximum-pool-size: 8

正式服不要用 root 空密码。
数据库字符集建议 utf8mb4，连接参数里保留 characterEncoding=utf8 兼容即可。

Redis 配置 ​

yaml
storage:
  mode: redis

redis:
  enabled: true
  host: 127.0.0.1
  port: 6379
  password: ""
  database: 0

Redis 适合队伍状态、申请、邀请、短期跨服请求。
如果 Redis 暴露到公网，必须设置密码和防火墙。

代理配置 ​

yaml
proxy:
  enabled: true
  type: velocity
  server-id: lobby-1
  custom-channel: "gtdungeonteam:main"
  legacy-custom-channel: "GTDungeonTeam"

type 可填：

text
velocity
bungee
waterfall
none

每个子服的 server-id 要和代理端服务器名保持一致。例：

yaml
# 大厅服
proxy:
  server-id: lobby-1

# 副本服
proxy:
  server-id: dungeon-1

副本目标服 ​

yaml
dungeon:
  id: forest
  target-server: dungeon-1

当队长在 lobby-1 开始 forest，而 target-server 是 dungeon-1 时，插件会走跨服开本流程。

如果 target-server 为空，或等于当前 server-id，就在当前服启动。

跨服开本配置 ​

yaml
cross-server:
  auto-start-on-target: true
  pending-expire-seconds: 120
  join-delay-ticks: 40
字段作用
auto-start-on-target玩家到目标服后是否自动启动副本
pending-expire-seconds等待请求多久过期
join-delay-ticks玩家进服后延迟多少 tick 再处理

join-delay-ticks 不要太低。部分服玩家刚进服时 PAPI、权限、背包、属性还没加载完，太早开本容易误判。

队长在 A 服、队员在 B/C 服时的流程 ​

假设：

  • 队长在 A 服。
  • 队员 1 在 B 服。
  • 队员 2、3 在 C 服。
  • 副本目标服是 dungeon-1。
  • 副本消耗 30 体力、100 金币。
  • 进入条件是某个变量大于 5。

队长点击开始后：

  1. A 服读取队伍数据。
  2. 检查执行者是否队长。
  3. 检查队伍目标副本。
  4. 检查队伍人数。
  5. 按副本 requirements.scope 检查变量条件。
  6. 按副本 cost.scope 检查体力、金币、物品。
  7. 创建跨服等待请求，写入共享存储。
  8. 通过代理请求把在线队员送到 dungeon-1。
  9. 预检查都通过后，按配置扣除体力、金币、物品。
  10. 队员进入 dungeon-1。
  11. 目标服延迟 join-delay-ticks。
  12. 目标服读取等待请求。
  13. 队员到齐或满足启动条件后，目标服调用对应副本适配器。
  14. 副本启动后记录运行状态。

如果没有任何队员能被传送到目标服，等待请求会取消。
如果扣款或扣体力失败，流程会返回失败，不继续开本。

条件和消耗的 scope ​

副本文件里：

yaml
requirements:
  scope: leader

cost:
  scope: leader

可用范围：

值说明
leader只处理队长
all-online当前子服在线队员
team-online同 all-online
members-online同 all-online

跨服时不建议轻易对所有子服玩家做本服 PAPI 判断。PAPI 大多只能读当前服务器在线玩家。需要全队条件时，最好把战力、职业、等级写入共享数据，再用统一变量读取。

邀请和申请跨服 ​

玩家上线时会写入最近所在服。队长邀请列表会显示同一套存储里已索引的玩家。跨服申请会写入队伍申请池。

一个玩家同时申请多个队伍时：

  1. 所有申请都会进入对应队伍申请池。
  2. 第一个队伍同意成功后，玩家加入该队伍。
  3. 其他队伍再同意时，会因为玩家已有队伍而失败。

这样可以避免一个玩家被多个队伍同时拉走。

检查跨服状态 ​

text
/gdt status

看这几行：

text
存储: redis/mysql/local
代理: velocity/bungee/waterfall
队伍/副本: 队伍数量 / 配置副本 / 可展示副本
适配器: 可用数量

再检查：

text
/gdt providers

如果目标副本服没有对应副本适配器，队伍能被传过去，但副本不会正常启动。

排错顺序 ​

  1. 单服 local 模式能不能创建队伍。
  2. 单服能不能选择副本并开始。
  3. 换 MySQL 或 Redis 后，重启两个子服，看队伍是否能共享。
  4. 打开代理桥，看玩家是否能被送到目标服。
  5. 目标服 /gdt status 看适配器是否可用。
  6. 最后再测试完整跨服开本。

不要同时改存储、代理、UI、副本插件。一次只改一层，问题会好定位很多。