脚本基础
常量定义
说明 Blue 引擎脚本中通过
说明
常量定义适合处理这类内容：
- 不会频繁变化的固定数值
- 重复使用的物品名、命令名、标识值
- 一组脚本都会用到的公共配置
如果你已经在多个位置反复写同一个值，就应优先考虑改成常量，而不是继续手写硬编码。
如果你要处理的是执行过程中会变化的状态值，改看 变量操作。
常量和变量有什么区别
常量和变量最核心的区别是：
- 变量用于记录运行过程中的状态，执行过程中可能不断变化
- 常量用于集中定义固定值，加载后在各处重复引用
例如：
- 玩家积分、剩余次数、当前步骤，更适合用变量
- 物品名、定时器编号、固定阈值、GM 命令名，更适合用常量
常见结构
常量可以集中放在 QuestDiary 功能脚本里，也可以直接写在某个脚本流程中按需声明。
常见结构如下：
[@常量]
{
#DEFINE $(常量1) 任意值 ←注释
#DEFINE $(常量2) 任意值 ←注释
}
这类写法的意思是：
[@常量]是常量加载入口- 花括号内部集中写这一组常量定义
- 后续脚本先调用这个入口，再直接使用常量名
如果你只是想在当前脚本里临时声明一两个常量，也可以直接写在 #ACT、#IF 后面的流程里，不一定非要单独拆成常量文件。
#DEFINE 声明常量
#DEFINE 用于声明一个常量。
语法
#DEFINE <常量名> <值> [注释]
参数
| 参数位置 | 参数 | 说明 |
|---|---|---|
| 1 | 常量名 | 常量标识，后续脚本中直接引用 |
| 2 | 值 | 常量实际表示的内容，可以是数字、名字、命令或标识 |
| 3 | 注释 | 可选，用于说明这个常量的用途 |
在功能脚本声明
常量.ini
[@常量列表]
{
#DEFINE $(常量1) 1000 ←常量1注释
#DEFINE $(常量2) 2000 ←常量2注释
}
直接在脚本中声明
如果常量只在当前脚本里使用，也可以直接写在脚本流程中：
脚本.txt
#ACT
#DEFINE $(常量1) 999999
#SAY
$(常量1)
这种写法适合临时常量、单脚本专用常量，或者你想把常量写得更靠近使用位置时。
怎么加载常量
常量定义完后，通常不会自动生效，而是先通过 #CALL 调到常量入口。
常见写法
#CALL <脚本地址> <@常量标签>
示例
[@加载常量]
#CALL [\功能配置\常量配置.ini] @常量
常量文件更适合在当前脚本的公共加载入口中统一 #CALL 一次，具体组织方式可结合 功能脚本组织 一起看。
怎么使用常量
常量加载后，脚本里可直接写 $(常量名)。
一个完整示例
[@活动常量]
{
#DEFINE $(活动开启等级) 50
#DEFINE $(活动传送地图) 3
#DEFINE $(活动传送X) 330
#DEFINE $(活动传送Y) 330
}
[@进入活动]
#IF
CheckLevelEx ? $(活动开启等级)
#ACT
MAPMOVE $(活动传送地图) $(活动传送X) $(活动传送Y)
#ELSESAY
等级不足，暂时无法进入活动地图
[@加载活动常量]
#CALL [\活动配置\活动常量.ini] @活动常量
这种写法的好处是：
- 配置集中在一处
- 主脚本可读性更高
- 后续调整地图、等级或坐标时，不必到处翻脚本
使用建议
- 一个功能里重复出现的固定值，优先提成常量
- 常量入口建议单独放一个标签，方便统一加载
- 常量名要尽量见名知义，不要写成难以判断用途的缩写
- 如果常量很多，建议按功能拆成多个常量文件，不要全堆在一个文件里
命名注意
某些版本下直接使用 #DEFINE $(XXXXX) 这种命名方式可能出现冲突，建议改用更稳定的命名方式，例如 DEF_XXXXX。
如果你当前项目已经大量使用 $(常量名)，应先按现有引擎版本实际验证；如果是新写功能，命名时应尽量避免过于通用、容易冲突的名字。