发脾气 - 装备耐久度模组

天际为玩家提供了堆积如山的装备，但一旦找到一件好武器或一套护甲，其物理状态往往就永远变得无关紧要了。

这严重破坏了锻造系统。如果一件物品在被玩家选择再次改进之前会永久保持强化状态，那为什么还要建立一个围绕“淬炼”装备的系统呢？《上古卷轴5》提供了众多正面强化阶段，却没有对应的低于正常状态的劣化机制。

在我自己的模组排序中——而这正是我做这些模组的初衷——我希望有一个实际的理由去重访铁匠铺，保养我的装备。现在，在一次艰难远征之后，我的装备可能真的需要打理了。

我也很喜欢《旷野之息》这类游戏中的装备耐久系统——只是不喜欢武器永久损坏的设定。

控制脾气 为装备赋予一段历史。其损坏状态的设计，旨在自然地融入《天际》现有的强化体系之下：



伴随你穿越废墟的剑，或许会变得残破不堪。你的铠甲或许能挺过一场恶战，却也无法全身而退。

优质材料之所以珍贵，不仅在于其属性更高，更因为它们通常能更有效地承受打击。更高级的装备也可能需要更珍贵的材料来维护，这使得较为廉价的装备能够在更长时间内保持实用与经济性。

武器和护甲不会永久损坏。然而，损坏到一定程度装备会变得非常低效，直到进行修理。



耐久度损失由事件驱动。装备不会仅仅因为被穿戴而损坏，也不会因为时间的流逝而降低状态。

磨损发生在实际战斗行动中，包括：

• 普通武器攻击
• 强力攻击
• 弓与弩的射击命中
• 武器与盾牌猛击
• 用武器或盾牌格挡
• 双持攻击
• 穿戴护甲时受到物理攻击
• 玩家对NPC所穿戴护甲的攻击
  

不同的行动会造成不同程度的磨损。重击、盾击、格挡和普通武器攻击对装备施加的压力并不相同。

淬炼装备抗磨损。精良及更高级物品的损耗速度更慢，且每提升一个淬炼阶段，保护效果都会增强。传奇装备的磨损率最高可比普通物品低60%。

命名正温度阶段还带有一个小的隐藏缓冲，因此刚升级的装备不会因为一次轻微碰撞就立即跌出新等级。

携带此物的角色 幽灵类型 攻击虚灵不消耗武器耐久，也不损坏虚灵所穿戴的装备。

主要磨损值、冲击乘数、材料乘数和护甲部位权重均可通过附带的INI文件进行调整。

武器不会损坏或完全无法使用。它们的状况可能会下降到一定程度，使武器伤害加成变得微乎其微，但不会降低到1以下。

本模组不会在视觉上改变装备模型或纹理。其效果是机制性和统计性的，而非外观性的。



当一件装备向下跨越到新的命名状态时，LYT可以通过以下方式通知您：



仅在物品实际改变等级时才会出现此提示——例如，从“瑕疵”变为“破损”，或从“破损”变为“损坏”。同一状态内的普通磨损则保持静默。若一次严重的冲击同时跨越多个阈值，仅会报告最终状态，而不会在HUD上堆叠多条信息。

根据恶化的内容，同一过渡可播放三种不同声音之一。

• 武器
• 重型护甲
• 轻甲
  

截至 v1.11.0 普通NPC仍然可以携带磨损的装备，但LYT不再在后台扫描所有加载的单元格。

初始条件仅在相关装备实际生效时才会被赋予——例如，玩家击中那件护甲、NPC用盾牌格挡，或NPC死亡后其装备变为战利品时。

符合条件的已装备武器、盾牌和护甲可能会获得从“有瑕疵”到“破损”不等的初始状态。每件已装备物品的状态结果相互独立，因此NPC可能携带一把受损的剑，同时身穿数件不同状态的护甲。

一旦指定，该状态将在NPC死亡或物品转移时保留，使缴获的装备得以保留战斗中的磨损效果。

初始NPC状态系统会排除不应随意随机化的装备，包括：

• 附魔装备
• 任务或别名关联装备
• 自定义命名物品
• 独特物品与明显的人工制品
• 绑定、不可游玩或无法丢弃的武器
• 法杖、衣物和珠宝
• 装备已损坏或强化超过正常状态
• 基础价值为1,000金币或以上的装备
• 属于追随者、潜在追随者或队友的装备
  

当NPC被玩家物理击中时，其护甲会继续恶化。

玩家的武器类型和材质将与NPC的护甲类型和材质进行比较，遵循敌人攻击玩家时所应用的相同耐久度原则。

NPC对NPC的战斗被有意忽略。这可以防止大规模战斗产生不必要的耐久度处理。

若NPC用盾牌成功格挡玩家的攻击，磨损将作用于盾牌，而非其他无关的身体护甲。若NPC未持盾格挡，则该次格挡不会损伤其身体护甲，而是将伤害转移至武器； 武器格挡是对武器最具破坏性的行为之一（仅次于撞击墙壁）。

重要： NPC装备状态目前不会减少NPC实际的武器伤害输出或真实护甲保护。NPC的武器也不会仅仅因为NPC使用它们攻击而持续损耗。

一旦玩家拾取破损装备，其状态将完全影响玩家的伤害、护甲防护和商人售价。



条件附加于实际库存物品上，而非全局地附加于其武器或护甲类型。

例如，你可能拥有：



这三者仍是独立物品，可分别保留完全不同的状态数值。

该条件设计为通过普通库存操作（如：）仍附着于指定物品之上。

• 装备与卸下装备
• 掉落与回收
• 存放在容器中
• 在背包之间进行交易或转移
• 从被击败的NPC身上搜刮装备
  

这同样适用于双持两把相同武器的情况。该模组利用玩家动画事件和精确的库存实例信息来区分左手和右手攻击，并对相应装备的物品应用磨损。

当无法安全确定责任物品时，模组会刻意跳过磨损事件，以免损坏错误的装备。



武器类别：
不同的武器类型对不同类别的装甲有更好的破坏效果。

武器类别 是那次互动的前半部分。 

当我提到武器类别时，我 指其为锤、匕首、剑、斧，并说明是单手还是双手。

LYT并不会将所有成功的命中都视为来自同一种通用武器。匕首、剑、斧、锤、巨剑、战斧和战锤各自拥有独立的打击效果，并且针对轻甲和重甲时有着不同的表现。 
刀剑斜倚 重度地 对付轻甲，斧头介于劈砍与钝击之间，而钉头锤和战锤则最适合砸击重甲。双手武器通常比单手武器对护甲造成更大的压力，尽管每种武器类型仍各有其优势与劣势。

弓和弩也是分开计算的。两者对轻甲都有不错的效果，但普通箭矢在应对重甲防护时威力会大打折扣。弩箭则能保留更多的穿透力，对重型盔甲依然具有相当的杀伤力，这使得弩在对付板甲及其他重型装备时更加得心应手。

然而，武器类型 只是结果的一部分。 


材料：
材料  攻击武器的属性会与其类别特性一同生效，因此同类武器中，精良武器通常比粗糙武器对护甲造成更大的耐久压力。 

例如，乌木匕首和铁匕首可能都使用匕首的武器特性，但乌木武器凭借更强的材料属性，仍会对护甲耐久度造成更大的损耗。

对于弓和弩的射弹命中，弹药现在也会参与计算。LYT将发射器材质与击中护甲的箭矢或弩箭材质相结合。默认情况下，弹药获得较大的份额，而匹配的发射器和弹药材质则会产生该材质原始加成的1.5倍。弓和弩的近战击打仍仅使用发射器本身。

目标护甲随后会根据护甲类型和材质应用自身的抗性。廉价或原始的护甲磨损得更快，而高级材料则能承受更多的打击。这意味着最终的磨损度由完整的交互共同决定——武器类别、武器材质、箭矢或弩矢的材质（如适用）、轻型或重型护甲分类，以及被击中的护甲材质。

默认材料进阶的示例包括：



完整的武器档案、材料表及其倍率都可以在INI中修改。

攻击的施展方式同样至关重要。相较于普通攻击，重击对武器和护甲造成的磨损显著更高，而格挡与盾击则使用各自独立的损耗值，而非被视为普通挥击。

用武器劈砍会对其造成极大的损耗，尤其是把弓或弩当作临时棍棒使用时。反复用剑格挡、将武器砸向墙壁、岩石或其他硬物，以及一般性地粗暴使用装备，都会使其磨损速度远快于正常攻击普通目标时的消耗。




怒火中烧并不会取代《天际》的锻造系统。

损坏的装备可在磨刀石或工作台上正常修理或改良。

成功的锻造强化会用天际所计算出的强化结果替换损坏状态。因此，一把损坏的剑在磨刀石上操作一次后，可能恢复为精良——甚至好得多，具体取决于玩家的锻造技能、专长、药水、附魔以及所安装的锻造大修模组。

结果由《天际》和你的其他模组控制，而非独立的LYT修复菜单。

我试验过渐进式修复——将物品从“损毁”修复至“破损”，再到“损坏”等等——但干净利落地实现这一功能需要对《天际》的制造菜单进行大幅度的干预。在我看来，这会损害兼容性，并可能影响稳定性，而收益却相对有限。

当前（共有）：

• 没有修理套件
• 无自定义修复菜单
• 无隐藏修理货币
• 无强制分段修复
  

使用普通的制作站并继续。这样可以让模组保持精简，并使其感觉像是原版游戏的自然组成部分。



大多数磨损值、冲击特性、材料倍率、抛射物-材料权重、护甲特性和装备部位权重都可以在以下位置修改：



修改INI后请重启《天际》。理想情况下，应在启动游戏前完成配置更改。

同伴ESP还包含：



此全局变量用作所有支持来源的耐久度伤害的实时倍率。

其默认值为： 1.0

例如在控制台中输入：

全局耐久度伤害提高10%。

该ESP已标记为ESL，因此不会占用完整的插件槽位。

v1.10.0 还新增了以下内容：



这是该模组的总开关，默认设置为 1.0. 在控制台中输入以下内容：

此开关特意设计为非破坏性。将其设置为 0 不修复装备或清除已存储的状态，不应被视为卸载清理功能。

ESP还提供：



两者均默认设为 1.0. 将两者都设置为全局 0 禁用该展示功能，但不禁用耐久度或公开的Papyrus状态事件。

同伴ESP还提供：



调试模式可以通过控制台来控制：



调试模式不会禁用或以其他方式改变耐久度系统本身。


LYT_Debug 诊断日志写入位置：



如果你使用Mod Organizer 2，请检查覆盖文件夹。

日志会在天际启动时重新创建，防止它在多次会话间无限增长。即使禁用调试模式，启动信息、警告和关键信息仍会保留；LYT_Debug 控制更详细的运行时诊断信息。





此模组不会修改原版武器、护甲、制作或等级列表记录。

因此，它应当与以下内容广泛兼容：

• 武器和护甲模组
• 锻造系统全面革新
• 专长系统全面翻新
• 战斗系统重制
• 经济与交易模组
• 模组新增制作系统
• 附魔装备
• 自定义命名的玩家装备
  

附魔和自定义命名的装备在玩家使用时可以正常损耗，它们仅被排除在NPC装备的随机初始状态系统之外。

使用标准《天际》武器类型和公认材料关键词的模组添加装备，通常会被自动检测到。

完全自定义的材料、特殊的装备栏位或非常规的武器记录，可能会回退到更通用的耐久度设置，如果无法安全识别，也可能被排除在外。

由于这是一个原生的SKSE插件，另一个修改完全相同引擎功能的DLL可能会与特定功能产生冲突。LYT会验证其所使用的引擎路径，并设计为安全失效，而非盲目覆盖现有的钩子。在发生此类冲突时，受影响的功能可能会自行禁用，而插件的其余部分仍继续正常运行。

没有任何MOD能保证与所有内容完全兼容，但避免常规记录修改并采用保守的失败机制，应能使兼容性问题相对较少。


可选签名装备兼容性
截至 v1.11.0 安装程序可以为以下内容添加更好的兼容性 签名装备 当检测到该模组时。

需要从内部修补两个脚本 专属装备。因此，如果你使用Signature Equipment，至关重要的是不仅要安装此兼容补丁（FOMOD会自动检测其是否存在），还要确保LYT覆盖Signature Equipment的现有脚本。

签名成长作为独立加成保留在具体的武器或护甲部件上。因此，LYT可以正常应用普通伤害、修理和淬炼，而不会将这些变化误认为签名成长。

只跟踪真实且持久的装备。法杖、已绑定或临时武器、衣物、珠宝以及天际中隐藏的徒手占位物都会被忽略。

在签名装备后安装“怒火失控”，并在提示时允许LYT的兼容性文件优先。

理想情况下，我建议你彻底干净地卸载Signature Equipment（通过MCM禁用，保存，卸载模组，重新加载存档，再次保存），然后配合LYT的补丁重新安装该模组，以确保一切运行顺畅。







LYT v1.10.0+ 为其他 SKSE/Papyrus 模组提供了一个小型公共 API。

对于普通玩家来说，这可能意义不大，但对于模组制作者来说，这将非常有帮助；这允许模组制作者制作模组，以检测任何指定物品当前的强化等级/归属。

该API特意聚焦于两项可靠的操作：

• 查询当前装备在武器手或辅助防具槽位中物品的精确状态。
• 在已验证玩家的装备穿戴情况向下跨越到另一个命名条件等级时，触发事件。
  

LYT本身不会向玩家的存档中添加持续运行的Papyrus任务、轮询循环或常驻游戏脚本。DLL负责发送事件，而SKSE现有的已穿戴物体功能则提供精确的已装备实例查询。



同伴ESP包含：



这是公共集成合约的版本，而非所展示的模组版本。API 110定义了下文记录的层级值与事件载荷。

全局表单ID可从带ESL标记的伴生ESP中通过本地表单ID解析得到。 0x00000D65:

GlobalVariable LYTVersion = Game.GetFormFromFile(0x00000D65, "Losing Your Temper - An Equipment Durability Mod.esp") as GlobalVariable

SKSE的 已磨损物品的耐久度百分比 可以查询当前装备的具体库存实例：

浮点型 变量 rightWeapon = WornObject.GetItemHealthPercent(akActor, 1, 0)
Float leftWeapon = WornObject.GetItemHealthPercent(akActor, 0, 0)
Float bodyArmor = WornObject.GetItemHealthPercent(akActor, 0, 0x00000004)
浮空护盾 = WornObject.GetItemHealthPercent(akActor, 0, 0x00000200)

手动选择器：

• 0 — 左手，或在提供槽位掩码时进行护甲查询。
• 1 — 右手。
  

LYT使用的支持的护甲槽位掩码：

• 头部，第30栏 — 0x00000001
• 身体，插槽32 — 0x00000004
• 手，槽位33—— 0x00000008
• 脚部，槽位37—— 0x00000080
• 盾牌，第39号槽位 — 0x00000200
  

这些查询可以针对玩家或其他角色执行。由于它们检查的是当前实际穿戴的实例，因此即使多个副本共享相同的基础形态，结果也依然可靠。

仅凭基础武器或护甲形态，无法可靠地区分背包中多个未装备的同名物品实例。因此，API 110不承诺支持任意的未装备重复实例查询。

• -1 — 缺失、无效或未解析。
• 0 — 普通或精炼：0.95及以上。
• 1 — 瑕疵：0.80 至低于 0.95。
• 2 — 磨损：0.60至0.80以下。
• 3 — 受损程度：0.40至低于0.60。
• 4 — 破损：0.20 至低于 0.40。
• 5 — 已摧毁：低于 0.20。
  

注册：

RegisterForModEvent("LYT_ItemConditionChanged", "OnLYTItemConditionChanged")

监听者签名是：

事件OnLYTItemConditionChanged（字符串eventName，字符串strArg，浮点数numArg，表单sender）
结束事件

事件参数如下：

• 发件人 — 变更后玩家物品所属的基础武器或护甲形态。
• numArg — 已确证的新状态。
• strArg — 一个紧凑的、以分号分隔的载荷，包含过渡细节。
  

载荷格式为：

v=1;old=<tier>;new=<tier>;kind=<weapon|heavy-armor|light-armor>;slot=<left|right|hex mask>;name=<display name>

有效载荷的 新= 字段是权威命名等级。这在精确浮点边界处至关重要，因为从 numArg 由于普通的浮点精度问题，可能会产生不同的结果。

自定义物品名称中的分号、等号和换行符会替换为空格，以免破坏字段布局。

仅当已认证玩家的装备穿戴评分向下跨越至更差命名等级时，才会发送该事件。一次跨越多个阈值的变更仅针对最终等级发送一个事件，而非多个事件。

以下情况不会生成此事件：

• NPC初始状态分配。
• 正在加载现有的存档。
• 正在拾取已损坏的物品。
• 通过死亡或物品转移保持状况。
• 通过锻造修理或改良装备。
  

此事件将持续生效，当 LYT_启用条件音效 或 启用条件通知 已禁用。设置主控 LYT_开关 到 0 禁用事件派发以及LYT的其余功能。

完整的示例监听器和查询脚本包含在：



该示例仅供开发者参考。它不附属于任何任务，也不会由LYT执行。

与 LYT_调试 设置为 1，原生日志会记录API就绪状态、层级转换、事件载荷、监听器数量、分发失败及汇总计数器。直接 GetItemHealthPercent 已磨损对象 调用属于集成的Papyrus脚本，因此LYT无法自动记录每次外部查询。

希望这段描述涵盖了所有内容；我还没有像我希望的那样彻底测试Papyrus功能，但我所做的测试似乎都完美运行。





安装过程非常简单：

• 天际 SE/AE 运行时 1.6.1170
• SKSE64（运行时版本1.6.1170）
• SKSE插件地址库
• 无需开启新游戏。
  

此版本专门为《天际》运行时1.6.1170编译。

更新中：
更新通常只需用新版本替换旧版本即可。让较新的文件覆盖较旧的文件。

然而..

注意：如果您使用LYT的签名装备补丁元素，最好进行“干净存档”。 先装备印记 

在MCM中禁用 > 保存 > 退出游戏
卸载签名装备 > 加载游戏 > 加载之前的存档 > 再次保存

通过上述操作，你现在拥有了一份“干净存档”（或者至少，在不借助Resavor的情况下，尽可能干净了）。

如果你现在使用带有签名装备补丁元素的LYT进行更新/重装，将来出现问题的可能性会大大降低。

LYT本身并不使用会永久写入存档的常驻Papyrus任务或游戏脚本。附带的`.psc`文件仅作为面向开发者的API示例，并非由模组执行。不过，签名装备补丁组件确实会这样做，因此才有了这一流程。

移除LYT不应损坏存档，但卸载任何游戏性DLL前，你仍应创建备份。为达到最彻底的卸载效果，请在卸载DLL、ESP和INI前，修复任何你特别在意的已劣化装备。





不幸的是，这个模组的性质最终要求使用原生DLL。

由于该模组包含已编译的可执行代码，为保持透明、便于审查和独立编译，现已提供完整源代码。

不要指望我会经常发布基于DLL的模组。

我通常倾向于尽可能通过Creation Kit、普通插件和Papyrus来实现功能。

在《Skyrim》模组社区中，DLL插件有时被视为天然更优越，但它们也有几个重要的缺点：

• 它们可能提供给最终用户更少的直接控制。
• 他们的编译内容若不借助专业工具或对应源代码，则难以直接检视。
• 与任何可执行文件一样，恶意DLL也可能包含有害代码。
• 当《天际》或SKSE经历重大运行时更新时，它们可能需要更新。
• 它们可能带来兼容性和维护方面的问题，而普通的基于插件或脚本的模组通常可以避免这些问题。
  

这并不意味着每个DLL模组都不安全或制作粗糙。它只意味着原生插件需要对其作者有更高程度的信任，并且值得适当的审查。

因此，我认为在发布一个时，源代码的可用性尤为重要。

依我个人的看法，在能够以可接受的代价提供所需行为的情况下，传统的Creation Kit和Papyrus方案仍然是更优之选。然而，在本例中，仅通过那些方法无法可靠地实现我所需的功能。