项目依赖
项目如何记录它用到的插件、某个插件缺失或不兼容时会发生什么，以及构建出的游戏里会带上哪些插件
项目会记录它的文档实际用到了哪些插件。这张表存在 .nlproj 清单里，由扫描项目得出，从不手写。它回答两个问题：一台机器要装什么才能打开这个项目，以及从它构建出的游戏里应该带上哪些插件
在工作区侧边栏的 项目 → 依赖 中查看
硬依赖与软依赖
| 类型 | 何时记录 | 插件不在时 |
|---|---|---|
| 硬依赖 | 项目引用了插件所拥有的类型——蓝图节点类型或控件类型 | 文档是坏的，Studio 会介入 |
| 软依赖 | 插件只写过项目存储 | 什么都不会坏，仅作提示 |
一个插件可以两者兼具：既是硬依赖、又存了数据的插件，仍然算硬依赖
什么时候写入这张表
- 打开项目时，Studio 先用已持久化的那张表做解析，再加载任何插件——这样在某个插件的
setup有机会注册任何东西之前，就已经知道该跳过谁 - 导出时，重新扫描并改写这张表，让导出的包精确记录它需要什么
- 手动，用依赖面板里的 Rescan
打开这个面板只会解析当前状态，不会写清单
扫描只会重新推导那些已加载且贡献了类型的插件的条目。缺失或被禁用的插件的条目会被原样保留——一旦丢掉，你在没装该插件的机器上打开项目的那一刻，这条要求就被悄悄抹掉了
状态
| 状态 | 含义 |
|---|---|
| Ready | 已安装，且版本兼容 |
| Outdated | 主版本号相同，但比项目创作时所依据的版本旧。仍会加载 |
| Missing | 本机未安装 |
| Incompatible | 已安装，但主版本号与项目创作时所依据的不同 |
| Disabled | 处于 Missing 或 Incompatible 的硬依赖。该插件在这个项目里被跳过 |
兼容性只看主版本号：2.4.0 满足按 2.1.0 创作的项目，3.0.0 不满足。无法解析的版本号一律按不兼容处理
被跳过意味着什么
处于 Missing 或 Incompatible 的硬依赖会让该插件在这个项目里被跳过。Studio 根本不会 import 它的入口，因此 setup 不会运行，它的节点、控件和操作也都不会注册——由错误的主版本注册的节点类型，可能改写它已经读不懂的文档。你会收到一条指名该插件的警告，项目照常打开
跳过是按项目生效的。插件在别处仍然保持已安装、已启用
软依赖永远不会导致跳过
构建出的游戏里带上哪些插件
打包依据的是这张表，而不是已安装列表：
- 只有硬依赖会被带上。 一个已启用、带 runtime 入口、但这个项目并没有用到的插件，不会进入包
- 用到的类型没有提供方，构建就失败。 如果项目用到的某个节点或控件，没有任何随包插件在
contributes中声明它，预览和导出会中止，并给出指明插件与类型的信息——而不是发行一个到了玩家机器上那个节点什么都不做的游戏 - 完全没有这张表的项目（从未扫描、也从未导出）会回退到带上所有已启用的 runtime 插件。扫描或导出一次，选择就变精确了
版本号是一份契约
对插件作者来说，这一节直接影响你的用户：
- 主版本号一变，所有按旧主版本创作的项目都会断。 那些项目会把你的插件标为 Incompatible 并跳过它。要打断兼容时才升主版本，别拿它表示「这个版本比较重要」
- 保持类型 id 稳定。 项目按字符串保存节点和控件类型。改名是任何版本号都描述不了的破坏——新增新类型，把旧的继续注册着
- 内置插件的版本跟随 Studio。 一次 Studio 更新就可能把某个项目变成 Incompatible；这套机制正是为这种情况建的