使用实例
在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。
实例是什么？
实例是地图构建时引用的VMF文件，编译时会与主地图合并。一个实例VMF可以简单到仅含单个刷子，也可复杂到包含完整谜题机关及其逻辑实体与输入/输出触发器。
何时该用实例？
实例的核心优势在于：一次修改，全局生效。若调整了按钮或门的造型逻辑，无需逐个修改地图中的副本（告别手动复制粘贴！）。尤其适合以下场景：
- 重复的游戏机关（按钮/门/传送装置）
- 复杂几何结构
- 精密的实体或I/O系统（如地图过渡）
- 高频复用的物件组合
从零创建实例
- 原点规则**：地图原点(0,0,0)将作为实例的基准点。例如将按钮底部置于原点，可确保实例放置时与地板完美贴合。
- 参数化设计
通过func_instance_parms实体实现动态配置： 1. 在实例中声明带`$`前缀的变量（如`$box_type`） 2. 关联到实例内实体的对应属性（如方块的"Cube Type"值） 3. 主地图通过func_instance的"Replace"字段实时修改参数
- I/O交互桥梁
若需与主地图交互，添加命名为`proxy`的func_instance_io_proxy实体： 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编辑器需保存地图后实例才会显示核心特性
- 解包实例不受贴图锁定影响
- 使用func_instance_origin的实例选择框可能显示异常
- replace参数顺序无关
- 添加$varname会自动创建参数槽
- 嵌套实例需"代理桥接"才能在I/O自动补全中显示
组件解析
- func_instance_parms
通过parm<num>模式添加额外参数（对应replace<num>字段），无描述文本但顺序自由
- func_instance_io_proxy
编译/反编译可能将OnProxyRelay输出添加数字后缀（如OnProxyRelay1）
设计哲学
实例本质是封装预制件（类似Unity的Prefab/虚幻引擎的Package），具有三大优势：
- 统一管理：修改实例源文件，所有引用自动更新
- 模块化开发：如装饰物集只需创建一次，全图复用
- 跨工程协作：预设库共享（通过实例化→解包流程）
> 性能提示：复杂实例编辑时频繁点击"Edit Instance"前务必保存地图！
解包妙用
通过顶部菜单"Instancing→Collapse Instance"可解包实例：
- 将预设转化为普通实体（脱离实例关联）
- 适用场景：导入基础结构→解包→自定义贴图
- 避免污染原始实例库