Background games redeemer zh CN
ASF 内置了一个特别的功能——后台游戏激活器，此功能可以在后台运作，帮助您批量激活 Steam 游戏序列号（可以加上游戏名字作为标记）。 如果您有大量的序列号需要激活，在完成批量激活前肯定会触发 RateLimited 状态，此时后台激活功能将十分有用。
后台游戏激活器仅对单个机器人有效，也就是说它不会采用 RedeemingPreferences 的设置。 如有需要，这个功能可以和 redeem 命令一起使用（或者代替它）。
有两种方式进行导入操作——通过文件或者 IPC。
ASF 会识别 config 文件夹下名为 BotName.keys 的文件，其中 BotName 是机器人的名字。 该文件必须遵循严格的固定格式，每行由游戏名称和游戏序列号组成，两者之间由 Tab 分隔，最后以一个换行符结束表示开始下一个条目。 如果存在多个 Tab，则第一项会被认为是游戏名称，最后一项会被认为是游戏序列号，中间所有内容将被忽略。 例如：
POSTAL 2 ABCDE-EFGHJ-IJKLM
Domino Craft VR 12345-67890-ZXCVB
A Week of Circus Terror POIUY-KJHGD-QWERT
Terraria ThisIsIgnored ThisIsIgnoredToo ZXCVB-ASDFG-QWERT
此外，您也可以使用只有游戏序列号的格式（相邻条目之间仍然有一个换行符）。 在这种情况下，如果可能，ASF 将会向 Steam 询问正确的游戏名称。 我们建议您自己标记所有序列号的名称，因为在 Steam 上激活的 Package 的名称不需要符合 Package 中的游戏，所以根据开发者填写的内容，您可能会看到正确的游戏名称、自定义包名称（例如 Humble Indie Bundle 18）或者完全错误的甚至是恶意的名字（例如 Half-Life 4）。
ABCDE-EFGHJ-IJKLM
12345-67890-ZXCVB
POIUY-KJHGD-QWERT
ZXCVB-ASDFG-QWERT
无论您选择哪种格式，ASF 都将在机器人启动时或者运行时导入您的 keys 文件。 在成功解析并忽略所有无效项后，所有正确识别的游戏将会被添加到后台队列，BotName.keys 文件将被自动从 config 文件夹移除。
除了上述游戏序列号文件外，ASF 也开放了可供任意 IPC 工具（包括我们的 ASF-ui）使用的 GamesToRedeemInBackground ASF API 端点。 使用 IPC 功能会更强大，因为可以使用您觉得合适的方式进行解析。例如使用自定义分隔符，而不是强制使用 Tab 分隔，甚至可以完全自定义序列号格式。
当游戏成功导入后，它们会被加入到队列当中。 只要机器人已连接到 Steam 网络，并且队列不为空，ASF 就会自动处理其后台队列。 如果一个序列号尝试激活完成并且没有返回 RateLimited 结果，它将会被移出队列并根据其激活结果写入位于 config 文件夹下的文件当中。当序列号被使用时（例如结果为：NoDetail、BadActivationCode、DuplicateActivationCode），将会被写入 BotName.keys.used 文件中，否则就会写入 BotName.keys.unused 文件中。 由于 Steam 网络不一定会返回序列号对应游戏的正确名称，所以 ASF 会使用您提供的游戏名称。这样您就可以根据需要使用自定义名称标记您的序列号。
如果在激活过程中帐户遇到 RateLimited 状态，队列会暂停一小时以等待冷却时间结束。 然后，激活过程将会从中断的地方继续，直到队列为空或再次出现 RateLimited。
假设您有一个包含 100 个序列号的列表。 首先您应该在 ASF 的 config 文件夹下创建一个名为 BotName.keys.new 的文件。 我们加上 .new 后缀是为了防止 ASF 在创建文件的那一刻立即读取该文件（因为它是一个空白文件，尚未准备好导入）。
现在您可以打开刚创建的文件并将 100 个序列号粘贴进去，如果需要，还应该修正其格式。 之后 BotName.keys.new 文件中应该正好有 100 行（如果末尾有空行的话就是 101 行），每一行的格式均为 游戏名称\t游戏序列号\n，其中 \t 是 Tab 制表符，\n 是换行符。
您现在可以将该文件从 BotName.keys.new 重命名为 BotName.keys，以便让 ASF 知道该文件已经准备好被导入。 重命名完成的那一刻，ASF 会自动导入该文件（不需要重启），在确认所有游戏都被解析并加入到队列后，该文件将被删除。
除了 BotName.keys 文件，您还可以使用 IPC API 端点，甚至也可以根据需要混合两种方式使用。
一段时间后，会生成 BotName.keys.used 和 BotName.keys.unused 两个文件。 这两个文件包含了激活过程的结果。 举个例子，您可以将 BotName.keys.unused 重命名为 BotName2.keys，以此将未使用的序列号分发给别的机器人，因为前一个机器人并没有使用这些序列号。 或者您也可以将其中未使用的序列号复制粘贴到其他文件留作他用。 需要记住的是，ASF 处理队列时，新的项目会被添加到 used 和 unused 两个输出文件中，因此建议等待队列完全清空后再使用这两个文件。 如果必须要在队列完全清空之前访问这些输出文件，应该先将需要访问的文件移动到别的文件夹，然后再对其做进一步处理。 这是因为 ASF 可能会在您处理这些文件的时候添加新的结果进去，这可能导致某些序列号丢失。例如，您读取了一个包含 3 个序列号的文件，然后删除了这个文件，但 ASF 在此期间向被您删除的文件内新增的 4 个新的序列号就丢失了。 如果您想访问这些文件，确保先将它们从 ASF 的 config 文件夹中移出，例如将其重命名。
同样也可以在队列已有游戏的时候导入别的游戏，只需要重复上述步骤就行了。 ASF 会正确地添加新条目到正在执行的队列中并最终处理它。
后台序列号激活器在底层使用了 OrderedDictionary，意思是游戏序列号将会按照文件中（或者 IPC API 调用）的顺序激活。 这意味着，如果一条序列号需要拥有另一条序列号所激活的产品才能激活，那么需要先激活的序列号应该写在另一条的前面。 例如，如果您有 DLC D ，它需要先激活游戏 G 才能被激活，这就需要始终将游戏 G 的游戏序列号排在 DLC D 的前面。 同样，如果激活 DLC D 之前需要先激活 A、B 和 C，那么这三个就应该放在前面（任意顺序均可，除非它们各自也有依赖关系）。
如果不按照上面所说的方式激活，就会导致 DLC 无法被激活并返回 DoesNotOwnRequiredApp，即使您的帐户在完成整个激活队列之后已经可以激活该 DLC，它也不会在此时被激活。 要想避免这种错误，就必须保证队列里的 DLC 始终列在游戏本体之后。
