# Glow My Teammates — 团队发光模组详解

作者：吉祥法师

## 模组概述

Glow My Teammates 是一款专为 Minecraft Java Edition 26.1-26.2 版本设计的服务端 Fabric 模组，其核心功能是让同一队伍（Team）的玩家能够相互看到对方身上的发光效果。该模组建立在原版队伍系统之上，不引入任何自定义队伍管理机制，也无需客户端安装任何额外模组即可正常工作。玩家可以通过精细的权限配置，自主决定谁能看到发光效果、哪些实体类型会发光，以及定位器栏（Locator Bar）是否遵循同样的规则。

自发布以来，该模组在 Modrinth 平台上已获得 152 次下载，累计 1 位关注者，被归类为管理（Management）、小游戏（Minigame）和实用工具（Utility）三类。模组采用 CC0-1.0 开源协议发布，源代码公开可查，支持英文和简体中文双语显示。

## 模组核心功能

### 工作原理

模组的运作机制基于 Minecraft 原版的队伍系统，当玩家加入同一队伍后，模组会自动为队伍成员添加原版的发光效果（即 0x40 发光标志），该效果会根据不同的观察者进行个性化定制。每个队伍都可以独立选择是否启用发光效果，只有通过 `/teamglow team add` 指令手动启用的队伍才会参与该功能。模组不会改变任何原版行为，除非玩家主动启用相关功能。

### 功能特性

玩家可以在三个主要维度上配置发光效果：首先是玩家队伍发光，这是最基础的功能，启用后同队玩家可以互相看到发光效果；其次是生物实体发光，通过将 `non_player_glow` 配置项设为 `true`，可以让处于已启用队伍中的生物也对队友显示发光效果；最后是定位器栏过滤功能，将 `locator_bar_teammates_only` 配置项设为 `true` 后，定位器栏将遵循非对称规则，已启用发光队伍的观察者只能看到自己的队友。

### 技术兼容性

模组需要 Minecraft 26.1 或 26.2 版本、Fabric Loader 0.18.4（对应 26.1）或 0.19.3（对应 26.2）、Fabric API 任意版本，以及 Java 25 或更高版本。在运行环境方面，模组完全支持专用服务器、单人模式和局域网联机。在单人模式中，模组虽会在客户端加载，但所有逻辑运算均由集成服务器处理，因此原版客户端连接到服务器时无需安装任何额外组件。

## 快速使用指南

### 基础配置流程

要快速启用团队发光功能，首先需要使用原版指令创建队伍并分配成员：通过 `/team add red` 创建名为 "red" 的队伍，再用 `/team join red @a` 将全体玩家加入该队伍。然后通过 `/teamglow team add red` 指令为该队伍启用发光效果。完成以上步骤后，同队玩家即可互相看到发光效果。

### 指令系统详解

模组的所有指令都通过 `glow-my-teammates.command.*` 权限节点进行控制，完全兼容 LuckPerms 权限插件。在没有安装权限插件的情况下，指令将回退到原版 OP 权限检查机制：管理类指令需要 OP 等级 2，只读类指令对所有人开放。

具体指令包括：`/teamglow on` 和 `/teamglow off` 分别用于全局启用和禁用团队发光功能（需要 OP 权限 2）；`/teamglow status` 显示全局状态和已启用的队伍列表（所有人可用）；`/teamglow team add <队伍名>` 和 `/teamglow team remove <队伍名>` 用于为指定队伍启用或禁用发光效果（需要 OP 权限 2）；`/teamglow team list` 列出所有已启用发光的队伍（所有人可用）；`/teamglow config` 显示当前功能开关状态，`/teamglow config <开关名> ` 用于切换指定功能开关（均需要 OP 权限 2）。

### 功能开关配置

模组提供两个主要的功能开关。`non_player_glow` 开关默认关闭，启用后队伍中的生物也会对队友显示发光效果，但需注意，开启该功能后，每个被追踪实体的实体数据包都需经过模组的逐包处理路径，在生物密集的农场区域可能会造成性能影响。`locator_bar_teammates_only` 开关同样默认关闭，启用后定位器栏遵循非对称规则：已启用发光队伍的观察者只能看到自己的队友，其他队伍的成员和未入队玩家都会被隐藏；而未启用发光队伍的观察者则不受影响，仍能看到所有玩家。

## 配置文件详细说明

配置文件存储在每个世界的根目录下，文件名为 `glow-my-teammates.json`。以模组版本 1.1.2 为例，配置文件格式如下：

```json
{
  "enabled": true,
  "teams": ["red", "blue"],
  "configVersion": [1, 1],
  "config": {
    "locatorBarTeammatesOnly": false,
    "nonPlayerGlow": false
  }
}
```

其中 `configVersion` 表示磁盘配置的架构版本，旧版本配置文件会在首次加载时自动迁移到新版本，无需手动编辑。通过指令进行的配置修改会以原子写入方式（临时文件加原子移动）保存，如果写入失败，系统会在聊天界面显示错误提示，确保配置变更不会静默丢失。

## 与原版机制的交互

### 发光效果兼容性

模组设计严格遵守原版机制，不会干扰任何已有的发光效果来源。光谱箭、药水效果、`/effect glowing` 指令以及 `setGlowingTag` 等功能均不受影响，模组只会在原有发光状态的基础上添加或清除自己的位标记。

### 团队删除即时响应

当队伍被删除时，模组会立即清理相关效果。具体来说，`/team remove <队伍名>` 指令执行后，观察者会立刻停止看到该队伍成员的发光效果，无需重新登录或等待刷新，彻底杜绝了发光效果残留的问题。

### 纯服务端设计

模组的服务端设计带来了多重优势。客户端无需安装任何模组，因为发光标志仅是实体数据中的一个位标记，原版客户端可以原生渲染。服务端内置了英文和简体中文翻译，即使使用原版客户端，指令反馈也能显示为可读文本。此外，模组刻意设计为第三人称视角下玩家不会看到自己的发光效果——发光玩家在 F5 视角不会看到自身发光，只有队友能看到，这是有意为之的设计决策，确保自身始终接收无发光版本的数据。

### 网络负载考量

每个发光实体在每次数据更新时，都会向每个队友发送一个额外的微小数据包。对于小型团队而言，这种网络开销可以忽略不计；但在拥有数十名玩家和大量发光实体（或开启了生物发光功能的密集农场）的服务器上，额外的带宽消耗会显著累积。因此，建议只对确实需要发光功能的队伍启用该效果，以保持最佳的服务器性能。

## 技术实现细节

### 权限系统架构

模组的权限系统设计灵活，所有指令均受 `glow-my-teammates.command.*` 权限节点控制。具体权限结构如下：`glow-my-teammates.command.on`、`glow-my-teammates.command.off`、`glow-my-teammates.command.status`、`glow-my-teammates.command.team.add`、`glow-my-teammates.command.team.remove`、`glow-my-teammates.command.team.list` 以及 `glow-my-teammates.command.config`。在没有 LuckPerms 等权限插件的情况下，系统自动回退到原版 OP 权限检查机制。

### 开发工具与许可协议

该模组使用 OpenCode 和 Claude Code 开发，基于 DeepSeek V4 模型辅助编码。模组采用 CC0-1.0 知识共享零版权声明协议发布，意味着任何人都可以自由使用、修改和分发该模组，无需获得额外许可。