Factorio MOD的安装、更新和恢复方法【Space Age适配】

在Factorio 2.0和Space Age环境中接触MOD，安全的做法是分开考虑游戏内Mod Portal的便捷性和手动管理mods文件夹的强大功能。
本文针对初次安装QoL类MOD的玩家，以及想要运营包括quality和Elevated Rails等官方追加MOD的玩家而写。

关键在于：掌握用户数据的位置，在更新、禁用和恢复前进行备份，然后根据依赖关系和启动日志进行操作。
我自己最初采取了严格的做法——先只装一个小型QoL MOD，查看日志，然后再扩展，正因为这样，我才能在没有任何存档事故的情况下顺利过渡到大型MOD。

安装Factorio MOD前需要了解的前置知识

适用版本和本文前提

本文适用于Factorio 2.0及以后版本。
MOD的安装渠道主要是游戏内"MOD"界面中的Mod Portal，以及浏览器版（factorio.com）的Mod Portal。
社区通常采用Mod Portal进行运营，但关于Steam Workshop的使用方式存在差异，建议查阅一手信息进行确认（官方通常推荐使用Mod Portal作为主要渠道）。

之所以要提前理清这一点，是因为Factorio的MOD运营并不仅限于"游戏本体的安装目录"。
存档、设置、MOD和script-output等都集中在用户数据端，根据『应用程序目录 - Factorio Wiki』所述，write-data的设置会改变存放位置。
换句话说，即使在同一台PC上，如果"查看的文件夹"不一致，也会导致明明装了MOD却游戏里看不到的初级但令人烦恼的错误。

2.0版本以后，原版和DLC以及追加MOD之间的界限变得更清晰了。
因此，如果还不习惯"官方追加内容也作为MOD进行管理"的概念，打开MOD列表时可能会有些困惑。
我在安装Space Age后，首先重新检查了DLC附带的追加MOD是否在MOD界面中启用，然后单独切换quality开关来理解其行为。
按照这个顺序操作，可以在添加社区MOD之前理解官方配置的外观，这样就不容易混淆了。

另一点需要注意的是，添加或删除MOD会损坏回放数据。在安装新版本之前，建议备份包含存档和设置的目录。前面提到的"先保护后操作"的流程在2.0环境中同样有效。

Application directory/ja

wiki.factorio.com

官方安装途径

在Factorio中安装MOD时，最自然的做法是通过游戏内Mod Portal搜索并安装。
从安装简便性、依赖关系处理的易用性，到更新追踪，初次入门这个方式最为稳定。
社区中，通过游戏内浏览器安装时必需依赖自动选择的操作也被广泛使用。

浏览器端factorio.com上的Mod Portal适合用于查找资料和确认依赖关系。
特别是当你想冷静地确认"这个MOD依赖什么"以及"在哪个版本系列中更新"时，其一览性优于游戏内。
从技术角度来说，『Mod portal API - Factorio Wiki』中的api/mods/{name}/full也能获取依赖关系数组。
对于处理大量MOD配置、服务器运营或考虑modpack固定的人来说，仅仅知道这个API的存在就能大幅改变视野。

这种方法的优点是版本固定和验证相对容易。
例如想保持大型MOD的旧版、避免更新导致的配置崩溃、保留复现环境等情况下，比游戏内安装更方便。
代价是依赖关系和兼容性需要自己管理。
如果缺少必需的前置MOD，启动时会直接停止；如果混入DLC必需的内容，会当场被拒。
另外，UI标签和设置默认值可能因版本而变化，实际表述和默认值请在游戏内设置界面确认。

想记录配置时，script-output/mods.txt可以列出所有启用的MOD及其版本。
这样以后重现时就不用靠人脑记忆"装了什么"，在验证环境中帮助很大。
Factorio的MOD管理与其说依赖专用启动器，不如说是通过官方Mod Portal、用户数据位置、日志和输出文件的组合来调整，这样理解会更清楚。

Mod portal API

wiki.factorio.com

Space Age和quality/Elevated Rails的整理

Space Age是2024年10月21日发布的付费扩展，结构上由3个追加MOD组成。
结合日语和英文的相关记述，内容规模相当大，新增4个星球、5种科学包、22座建筑、30种中间产品、5种武器、2种敌人和29个成就。
作为原版的延伸开始接触，到中途会完全踏入另一个阶段，规模大到接近"另一款Factorio"。

重点是Space Age的追加内容不是"直接烧进游戏本体的固定功能"，而是MOD界面中可见的管理对象。
因此安装后打开MOD列表时，"哪些是官方要素，哪些是社区MOD"初看不清楚，但作为普通MOD管理在同一界面中完全可以把握。

其中quality有些特殊，如『品质 - Factorio Wiki』所述，可以作为独立MOD启用，但使用需要Space Age所有权。
这一点实际上很关键，有Space Age不代表必须总是启用quality。
我在导入后，先只切断quality玩了几小时，然后启用来看差别。
这样操作能更容易地从体感上掌握配方、装备感和量产线的意义在哪里改变。

Elevated Rails的整理方式在感覉上也接近quality。
Space Age作为官方要素的Elevated rail是其功能，但Mod Portal上也有多个社区MOD与之相关。
也就是说，MOD列表中看到"与Elevated Rails相关的名称"时，含义并不统一。
需要分清是DLC配置要素的追加MOD还是扩展、前推或调整该功能的社区MOD。

学会这种区分后，在Space Age环境中增加MOD时的判断会轻松很多。
先理解官方3个追加MOD和quality的关系，再叠加QoL或大型MOD。
Factorio 2.0之后的MOD安装，仅仅按这个顺序看待就能大幅降低事故率。

MOD的安装方式有两种：游戏内Mod Portal和手动安装

游戏内Mod Portal的安装步骤

最不容易出错的是通过游戏内"MOD"界面直接使用Mod Portal的方法。
Factorio的这条路线非常直截了当，搜索、安装、更新的流程在一个界面内完成，这是其优势。
特别是在安装数个QoL类MOD的阶段，比手动追踪依赖关系方便得多。

实际流程非常简单，从主菜单打开"MOD"，在安装标签页搜索想要的MOD名称，选择目标后安装即可。
社区广泛认知的是，这种方法往往会自动选择必需依赖，初学者受益最大。
例如单独无法运行的库类MOD的情况，游戏内浏览器端也会追随处理。

安装后MOD会添加到列表，有时以启用状态显示。
重要的不仅是能否安装，还要看启动时是否无错误地通过加载。
依赖的自动处理很方便，但不会完全负责兼容性。
大型MOD或DLC前置的配置中，安装本身可以成功但在加载阶段停止。

从技术角度说，『Mod portal API - Factorio Wiki』也整理了MOD信息获取和下载规范，api/mods/{name}/full同样能获取依赖关系数组。
日常游戏无需直接接触API，但了解游戏内浏览器能在查看依赖时方便处理的背景，会更理解为什么这个方法对初学者友好。

账户创建·Steam关联的注意事项

使用游戏内Mod Portal时容易卡壳的是，下载有时需要factorio.com账户。
即使通过Steam购买了Factorio，MOD的获取途径不是直接连接Steam功能，而是涉及官方Mod Portal端的认证。

因此，即使是Steam版购买者，创建factorio.com账户并与Steam账户关联也会让流程更清晰。
这样做的话，从游戏内搜索MOD并直接安装的流程会很稳定。
反之，如果这种绑定含糊其辞，容易导致"游戏本体在运行，但只有MOD下不了"的局面，初次导入时容易造成困惑。

Space Age环境中这一点特别重要。
官方追加要素也在MOD列表的语境中可见，DLC相关元素和社区MOD出现在同一界面。
如果认证这块也混乱，就很难区分是安装失败、所有权问题还是依赖错误。
我在构建新环境时的习惯是，先在游戏内确认登录状态，然后再接触MOD。
这一步骤能大幅加快原因排查速度。

手动安装（mods文件夹放置）和zip的处理

手动安装的基本做法是将分发的zip直接放到mods文件夹。
很容易想象需要解压后只放里面的文件夹，但通常zip原样放置的思路就足够了。
Factorio的用户数据端有mods文件夹，如前所述，如果改了write-data，那个设置目标才是实际的放置位置。

这种方法的优点是版本固定和验证相对容易。
想保持大型MOD的旧版、避免更新导致的配置崩溃、保留复现环境等情况，比游戏内安装更方便。
代价是依赖关系和兼容性需要自己管理。
如果缺少必需的前置MOD，启动时会直接停止；如果混入DLC必需的内容，会当场被拒。

容易被忽视的是不要把同一MOD的多个版本放在一起。
社区中已知，把同一MOD的不同版本并排放在mods文件夹会导致启动失败。
我在手动安装大型MOD前，每次都检查mods目录下有没有重复的同名zip或同名文件夹。
仅这一项检查就能大幅减少启动失败。
这在实务中很朴实，但最有效。

如果手动调试配置，看日志就能理清加载顺序和停止位置，把所有启用的MOD和版本输出到script-output/mods.txt后，以后比较配置也会简单。
在排查冲突阶段，这份列表的价值出乎意料地大。
关于容易兼容性卡壳的组合，结合后面提到的配置整理思路来看会更好处理。

安装方式的选择

安装方式没有优劣之分，而是根据要做什么来选择才实际。
初次QoL安装或日常游戏，游戏内Mod Portal明显更轻松。
搜索、安装、依赖也会在一定程度上自动处理，所以配置扩展的初速非常快。

另一方面，想版本固定、重点验证复现、特定配置保全，手动安装更合适。
zip放置和管理的方式虽然朴实，但能在不被更新左右的前提下保持相同状态是大优势。
在接触Krastorio 2或Space Exploration这样的大型配置时，这种稳定性的价值就很明显了。

两者的区别简单说就是，游戏内Mod Portal是"安装的便捷性"，手动安装是"配置的固定性"。
但手动管理需要自己拾起依赖不足和冲突，所以不习惯的话一次性大量安装容易卡壳。
从这个意义上说，先从游戏内小规模开始，有需要再转向手动的流程比较自然。

详细的角度可以从兼容性检查的视角分开看"依赖""本体对应""加载顺序"，这样会更容易理解。

mods文件夹和用户数据目录的位置

按OS分类的用户数据和mods文件夹

Factorio中，MOD、存档、设置文件基本上由用户数据目录管理。
手动安装中要接触的mods文件夹也在这里，理解为与存档和各种设置同属一个保存地点会更清晰。
路径因OS而异，准确的结构在『应用程序目录 - Factorio Wiki』中有总结。

先掌握常用的默认路径，Windows是%APPDATA%\Factorio\mods，Linux是~/.factorio/mods，macOS是~/Library/Application Support/factorio/mods。
这里还有saves和配置相关文件，与其把MOD看作独立物，不如把它看作"Factorio用户数据的一整套"在实务中不容易搞混。

我在Windows和Linux的双系统环境中游玩时，比起单独追踪mods，把modssavesconfig作为同一父目录单位来看压倒性地轻松。
备份和同步的单位一致，这样就避免了"这个环境只有存档新""那边只有设置旧"之类的事故。
在大型MOD配置间频繁切换时，这个差别效果很显著。

write-data选项的影响

容易被忽视的是，实际的保存位置不是固定在默认路径的。
Factorio可以通过config/config.ini的write-data设置改变用户数据目录的位置。
如果改了这个设置，MOD的保存位置和mods文件夹的位置也会跟着改。

换句话说，"Windows应该在%APPDATA%\Factorio\mods"的想法在使用write-data的环境下会白费力。
不仅是mods，saves、设置和script-output都会一起移动，手动安装、备份、恢复的任何操作都以这个设置为前提。
前面提到的zip放置操作，实际上是针对write-data指向的目录。

理解这个规范后，多环境管理会相当清爽。
我在双系统环境中明确指定write-data，让用户数据的位置保持一致后，备份和同步一下子就好处理了。
不是追踪mods本身，而是把保存位置的父目录整体固定，这样想能提高配置的再现性。

存档·设置·player-data.json的关系

用户数据目录下除了MOD和存档，还有配置和账户相关信息。
其中要掌握的是player-data.json。
这不仅是外观设置的保管地，还被视为包含Mod Portal令牌的文件。
当梳理游戏内MOD获取和API使用周边的事项时，知道这个文件的角色能让情况更清楚。

整理一下，mods是安装的MOD本体，saves是运行中的工厂数据，各种配置文件是操作和显示的环境，player-data.json是玩家信息和Mod Portal认证的辅助信息。
都在同一用户数据目录，备份和迁移时与其只看某部分，不如按关联整体把握。

了解这个结构后，环境迁移或恢复时就不容易出现"MOD恢复了但登录状态不同""有存档但设置没恢复"这样的错位。
Factorio的文件操作有些生硬，但一旦明白存档、设置、认证信息共用同一基础，就能很清楚看出触哪里会改什么。

更新、禁用、备份的安全运营流程

更新前检查清单和备份

本体更新或新MOD安装，事故率的大差别来自安装前的退避。
Factorio的MOD、存档、设置集中在同一用户数据目录，更新前不如把单个文件分别退避，把父目录整体ZIP化效果更稳定。
『应用程序目录 - Factorio Wiki』也以这个保存位置为基准整理。

实务中，比起只单独退避mods和saves，整体把用户数据目录打包成ZIP后，复现时速度更快。
我也在大型更新前这么做，有不匹配也能快速回复。
特别是Space Age这样官方追加要素规模大的更新，配置变化一下子涌入，这一步骤的价值非常高。

更新前检查简化为下面3点最好处理：

1. 把现在的用户数据目录整体退避
2. 正在进行的存档另存一份
3. 明确意识更新是否会破坏现在的MOD配置再应用

其中存档复制特别重要。
MOD的添加或删除不仅影响加载可否，还关系到回放兼容性。
『回放系统 - Factorio Wiki』所述，MOD配置改变时回放数据会损坏。
平时游玩容易忽视，但以后想复现或验证时就会很要紧，所以更新前的存档复制与其说是保险，不如说是正常运营。

禁用·恢复（回滚）的基础

更新后出现不适，与其急着找原因，不如先看能否回到直前的稳定状态更快。
Factorio的MOD问题往往不是坏了1个文件，而是"本体·MOD·存档的组合"引起的，所以回滚也要按这个组合单位考虑。

禁用的第一步是分开添加了哪个MOD或更新了哪个MOD。
但仅仅关闭复选框不一定能恢复原样。
存档能读取但内容变质，或反过来存档本身以那个MOD为前提保存了。
特别是生产链或实体增加类的MOD影响范围广，关掉它瞬间工厂就变了。

因此恢复的优先级是"删除有问题的MOD"不如把更新前复制的存档和更新前的mods状态一起恢复更稳定。
这样就容易避免"存档老、MOD新"这种半吊子状态。
前面提到按父目录单位处理用户数据的想法在这也有效。

回滚时容易忽视的是自动启用新MOD的设置。
mods文件夹里放的zip，下次启动时那个MOD会启用状态出现。
明明恢复了结果还有多余zip留下，只靠那个就容易再发。
回复时要把"放了什么文件"和"启用了什么MOD"同时对齐才对。

多版本混存风险的避免策略

想保留旧版的场景很常见。
验证用配置、进行中存档的延命、特定MOD的兼容等待等原因五花八门，容易出现多版本混存。
在同一mods文件夹放新旧zip，本体也继续更新，就分不清哪个组合在运行。
问题发生时排查困难，这是最典型的情况。

需要保留旧版的话，运营上最好手动保证只有1个版本。
平时游玩的配置和验证配置不该共用一个地方，"只放现在这个存档用的MOD群"比让两者共存更能减少读取时误解和更新遗漏。
特别是手动安装对版本固定有利，但也容易留下残骸，不整理的话就成了事故温床。

Space Age周边因为官方追加要素和常规MOD看起来接近，配置边界容易模糊，也很讨厌。
以DLC为前置的MOD和不以此为前置的MOD共存时，表面上名字相近但意义不同。
我为了避免这种混淆，验证时会让mods文件夹保持精简。
宁可输入少量装便利，不如把工厂简化为1个配方的感觉，环境也最小化效果反而更快。

多版本要并行维持的话，本体、存档、MOD一整套要作为同一单位分开，这一点必不可少。
只留某一个的运营容易整合崩溃，以后回头也没法再现。
Factorio的MOD管理导入时的差不如维持时的差大，避免混存、"现在用1个明确配置"本身就是强力的安全策略。

依赖关系、兼容性、冲突的区分方法

依赖关系的读法

无法启动的MOD大多数首先源于依赖关系的误解。
Factorio的Mod Portal各页面通常列有依赖关系，分发文件的info.json里也有依赖信息。
从游戏内Mod Portal安装时有时会自动拾取必需依赖，但手动安装或版本维持时很快就要自己读这个信息。

诀窍是不看"这个MOD能单独运行吗"，而看MOD前提了什么。
例如库类、翻译辅助、特定大改前置的扩展，光看名字很难判断依赖的重程度。
Mod Portal上的说明文比不上依赖栏与启动可否的直接关系，有时很显著。

机械地确认的话，用『Mod portal API』查api/mods/{name}/full信息。
这个full终点能获取dependencies数组，游戏内显示追不到的时候非常便利。
多人重现同一modset或整理某MOD要求什么时，比起显示，API更接近内部信息，排查会更快。

我在添加大型MOD时先看依赖栏。提前掌握这个就能避免"想加个方便小工具结果竟然前置别的基盘MOD或DLC"的事故。

Factorio本体版本对应的确认

依赖齐全了，本体版本不对的话加载也停。
Factorio的MOD中，MOD为哪个本体版本制作的极其重要。
特别是大更新直后，人气MOD也容易在追进前遗留，安装步骤本身比在这卡壳更常见。

Space Age发布日是2024年10月21日，这时间后就开始大量迁移到2.0系和DLC兼容。
在这种大节点，昨天还稳定的配置更新后马上全面显露非对应。
而且Space Age表面上是追加MOD，实际牵涉官方拓展构成，用对普通MOD的"名字看得到就能用"的判断就容易跑偏。

Mod Portal的个别页面有本体版本对应信息，分发数据的元信息也能追。
要看的点很简单，自己的Factorio本体世代和MOD端的对应世代是否一致。
想在旧版用进行中的存档延命，与其追新MOD不如把当时的本体和当时的MOD组合固定反而稳定。
前面提到的"整体处理配置"的想法在这也有效。

冲突时的错误信息和日志读法

冲突发生时，凭感觉找犯人不如顺着错误信息和日志顺序追更快。Factorio启动时输出信息很直白，问题不在掉线的事实，而在哪个读取阶段停了。

错误画面首先要拾取的是失败MOD的内部名。
表示名很友好，但错误中往往用内部名，搞反了就开始找别的。
更详细的话看『日志文件』中的加载顺序和失败位置。
日志会留下"到哪读得还好"，容易拾起"A看起来坏了实际是B不足"这种错位。

日志看的不是派头的英文错误全文，而是稍前的地方。依赖不足、版本不一