Zh/Working with instances

在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。

实例是什么？

实例是地图构建时引用的VMF文件，编译时会与主地图合并。一个实例VMF可以简单到仅含单个刷子，也可复杂到包含完整谜题机关及其逻辑实体与输入/输出触发器。

何时该用实例？

实例的核心优势在于：**一次修改，全局生效**。若调整了按钮或门的造型逻辑，无需逐个修改地图中的副本（告别手动复制粘贴！）。尤其适合以下场景：

• 重复的游戏机关（按钮/门/传送装置）
• 复杂几何结构
• 精密的实体或I/O系统（如地图过渡）
• 高频复用的物件组合

从零创建实例

• • 原点规则**：地图原点(0,0,0)将作为实例的基准点。例如将按钮底部置于原点，可确保实例放置时与地板完美贴合。

1. 1. 1. 参数化设计

通过func_instance_parms(en)实体实现动态配置： 1. 在实例中声明带`$`前缀的变量（如`$box_type`） 2. 关联到实例内实体的对应属性（如方块的"Cube Type"值） 3. 主地图通过func_instance的"Replace"字段实时修改参数

1. 1. 1. I/O交互桥梁

若需与主地图交互，添加命名为`proxy`的func_instance_io_proxy(en)实体： 1. 为每个需接收的输入创建对应输出："OnProxyRelay" 2. 主地图通过"instance:<实体>;<指令>"格式通信

> **命名技巧**：实例内需直连的实体建议以"@"开头命名（如"@elevator_core"），主地图可直接对其发送指令——Valve电梯系统大量采用此方案。

func_instance_parms与实体命名的关键细节

当实例实体名称被参数化时，主地图的I/O必须指向**最终合并名称**（VBSP编译时自动生成）。命名规则如下（假设采用"前缀模式"）： > (func_instance的Fix Up Name值)-(实例实体原名)

例如：若实例内实体名为`button_trigger`，主地图func_instance的Fix Up Name设为"Lobby"，则主地图中该实体名为"Lobby-button_trigger"。

技术深潜

注意:Hammer编辑器需保存地图后实例才会显示

1. 1. 1. 核心特性

• **解包实例**不受贴图锁定影响
• 使用func_instance_origin的实例选择框可能显示异常
• replace参数顺序无关
• 添加$varname会自动创建参数槽
• 嵌套实例需"代理桥接"才能在I/O自动补全中显示

1. 1. 1. 组件解析

• • func_instance_parms**

通过parm<num>模式添加额外参数（对应replace<num>字段），无描述文本但顺序自由

• • func_instance_io_proxy**

编译/反编译可能将OnProxyRelay输出添加数字后缀（如OnProxyRelay1）

1. 1. 1. 设计哲学

实例本质是**封装预制件**（类似Unity的Prefab/虚幻引擎的Package），具有三大优势： 1. **统一管理**：修改实例源文件，所有引用自动更新 2. **模块化开发**：如装饰物集只需创建一次，全图复用 3. **跨工程协作**：预设库共享（通过实例化→解包流程）

> **性能提示**：复杂实例编辑时频繁点击"Edit Instance"前务必保存地图！

解包妙用

通过顶部菜单"Instancing→Collapse Instance"可解包实例：

• 将预设转化为普通实体（脱离实例关联）
• 适用场景：导入基础结构→解包→自定义贴图
• 避免污染原始实例库

扩展阅读

• 实例系统原理解析(en)
• func_instance实体手册(en)
• 参数化配置指南(en)
• I/O代理全解(en)
• 求生之路2实例应用(en)