动态持久形态重想 - DPF RE

我真是太感激了 耶稣 为了所有的帮助 ❤️，
同时，也感谢QTR团队的所有成员，他们一直 蒂亚戈（这其实就是他的模组）， Raven和 量子帮了我大忙的人， 
以及我在旅途中遇到的所有其他模组作者和朋友们！
但特别的是 维兹卡 (顺便一提，这记进球正是来自角球区的远射！)
你可以的 投票 为下一个模组/更新以及测试版做准备 这里
如果你想查看 Discord 🫠 

如果你是模组作者🫠

而且不想处理这些表格的麻烦，填写表格之类的破事。
使用 动态表单生成器 这个mod本来就是为配合它而打造的。🫠

DFG让你可以通过游戏内菜单创建和编辑动态表单，之后你可以将生成的J文件随模组一同发布。DFG会读取这些文件，向DPF RE请求正确的持久化槽位，重新创建表单，并为你填充游戏数据。

简而言之：如果你想要完整的SKSE/Papyrus控制，请直接使用DPF RE。
如果你只想定义表单并让工具处理运行时工作，请使用DFG。

给模组作者的另一条重要免责声明 🫠

DPF RE仅创建并保留持久化运行时FormID槽位。它不会自动将游戏数据、关键词或效果填充到已创建的表单中。、模型、参数、描述或自定义行为。

这部分由使用DPF RE的模组负责，在每次游戏启动时填充表单。

如果你的模组需要创建复杂表单、恢复自定义数据、重建效果，或确保生成的表单在多次加载中保持一致，强烈建议使用C++ SKSE API，而不要仅依赖Papyrus。
Papyrus支持适用于更简单的使用场景，但SKSE为模组作者提供了更多控制权、更精准的时机把控，以及与《天际》运行时系统更安全的集成。🫠

 就用吧 动态表单生成器 🫠

与原版DPF有什么不同？

原版DPF和DPF RE解决的是同一个基本问题：允许模组创建可在之后恢复的运行时表单。然而，DPF RE采用了不同的方法，并提供了若干新的可能性。

自动多插件容量

原版DPF使用单一的DPF.esp文件。

DPF RE可以自动检测并使用一系列完整插件：

- DPF.esp
- DPF 2.esp
- DPF 3.esp
- 以此类推

当当前插件可用FormID槽位用尽时，DPF RE会自动从下一个已安装插件继续分配表单。

无需安装额外的DPF插件，除非确有需要。若当前已安装的所有DPF插件均已满载，DPF RE将在游戏内显示提示信息，告知用户下一步必须安装哪个插件。

之前使用过的DPF插件必须保持安装并启用状态，因为它们继续拥有已分配给它们的表单。

稳定的插件和本地表单ID配对

原始的DPF是围绕单个插件设计的，因此通常本地FormID就足以标识生成的表单。

DPF RE通过以下方式识别每个持久化槽位：

DPF插件 + 本地FormID

例如：

DPF.esp | 000801
DPF 2.esp | 000801

两种形态可以同时存在，互不冲突。

所有者与钥匙系统

DPF RE 允许每个模组使用稳定的所有者与键对来预留形态。

例如：

MyMod | 火焰专精

该模组可以在另一次游戏开始时再次请求相同所有者/密钥，并获得相同的持久槽位，无需手动管理分配顺序。

专为运行时重建的表单设计

原始DPF曾尝试序列化并恢复所生成表单的完整数据。

DPF RE 会保留表单的身份标识：

哪个DPF插件拥有它
- 其本地表单ID
- 其形态类型
- 其模组或脚本的所有者
- 其持久键

模组作者、SKSE插件、Papyrus脚本或动态表单生成器负责在游戏启动时填充实际的游戏数据。

DPF RE 专为与 Dynamic Forms Generator 直接配合使用而设计。

更明确的所有权和清理机制

DPF再生可释放：

- 一种通过其所有者/钥匙的形式
通过其DPF插件和本地FormID的一种形式
- 属于特定拥有者的所有表格

这使得模组能够更安全地管理和清理仅由其拥有的表单。

精简全局注册表

DPF RE并未通过存档序列化回调存储完整的表单记录，而是使用了一个紧凑的全局槽位注册表，存储于：

`Data/SKSE/Plugins/DPF_Cache.bin`

此注册表独立于单个存档，可确保生成的形态在所有权与身份标识上，在不同游戏会话之间保持一致。