1 个不稳定版本
0.1.0 | 2022年7月18日 |
---|
#242 在 国际化 (i18n)
130KB
2.5K SLoC
smallworld
...尽管山川分离,海洋辽阔...
smallworld 是一个小工具,可以创建不含区域限制的 openingTitle.arc
文件,用于 New Super Mario Bros. Wii,无需代码修改,文件大小增加最小(约 0.3%)。它还可以将 openingTitle.arc
从一个区域转换为另一个区域。
用法
从 发布页面 下载您操作系统上最新版本的安装包。每个版本都包含多个构建;选择与您的系统架构匹配的版本(如果您不确定,x86_64
是最常见的)。
命令行界面快速概述
将以下命令中的 "smallworld
" 替换为您选择的二进制文件的完整名称。
在原地制作不含区域限制的 openingTitle.arc
smallworld openingTitle.arc
将 openingTitle.arc
转换为特定单个区域(例如,日本)
smallworld --to J openingTitle.arc
另存为不同的文件名而不是覆盖输入文件
smallworld -o modified.arc openingTitle.arc
忽略文件的冲突副本并仅选择 EU 版本*
smallworld --ignore-conflicts openingTitle.arc
查看完整用法信息
smallworld --help
*默认行为。您可以使用 --from
来配置如何解决冲突;有关更多详细信息,请参阅 --help
。
许可证
GNU GPL v3。有关更多信息,请参阅 "LICENSE" 文件。
常见问题解答
是什么? openingTitle.arc
是 NSMBW 中包含标题屏幕上显示的标志图像以及相关布局和动画文件的存档文件。其中所有文件名称在不同地区略有差异——例如,布局文件在美国版中是 openingTitle_US_00.brlyt
,在国际版(EU)中是 openingTitle_EU_00.brlyt
,在日版中是 openingTitle_13.brlyt
。这些文件名在代码中是硬编码的;因此,每个 openingTitle.arc
都与一个特定地区相关联,如果在其他地区使用将会导致游戏崩溃。
由于 NSMBW 的不同版本整体上非常相似,因此通常为模组支持其中几个版本,通常至少是 3 个(US、EU、JP)。创建自定义 openingTitle.arc
的传统方法是为每个地区手动创建多个副本,并在运行时根据发现的哪个游戏区域来加载正确的版本(openingTitle.arc
在不同地区也位于不同的路径)。
smallworld 提供了一个更好的解决方案,即低开销、地区通用的 openingTitle.arc
。这是通过向存档的文件名表中添加冗余的文件名来实现的,它们都指向相同的内部文件数据。这样,无论游戏使用哪个文件名,查找都会成功。
为什么我应该使用这个? 处理 openingTitle.arc
至关重要。如果您的模组只支持一个地区,将会锁定掉大部分潜在玩家。
传统的 openingTitle.arc
解决方案有一些缺点
- 您的模组需要包含多个
openingTitle.arc
的副本,而这些副本有 99% 是相同的。 - 如果您想再次编辑您的标志,您必须在之后再次手动进行文件重命名过程。
- 您可能会犯错或出现打字错误(例如,很容易忘记日版文件名为 "13" 而不是 "JP_00"),除非您有每个游戏版本的可用副本进行测试(并且愿意真正这样做),否则您将无法注意到。
- 大多数人不会费心包括韩版和台版的
openingTitle.arc
,因为那些游戏版本相对罕见,制作更多副本文件只需要更长的时间。
而这一切,您都可以让 smallworld 为您处理。快速轻松地创建单个地区通用的 openingTitle.arc
,将其放入您的模组中,您将再也不用手动处理。
为什么不使用代码破解来使文件名一致呢? 如果您愿意,请随意。这只是另一个不需要代码破解的不同解决方案。
它与新 SMBW 一起工作吗? 是的。
如果文件在不同地区的路径不同,如何在模组中共享单个文件? 这可以通过 Riivolution XML 来实现(您使用 Riivolution,对吧?)。为每个地区的 openingTitle
文件夹添加一个条目,并将它们都指向您模组中的单个共享文件夹。
我该如何 编辑 地区通用的 openingTitle.arc
?其中包含如此多的重复文件! 您有两个选择
- 三步过程:使用
--to
选项通过 smallworld 运行它以转换为单个地区(选择其中的任何一个),按常规编辑文件,最后使用 smallworld 再次将其转换为地区通用。 - 两步流程,如果不小心操作则稍微有风险:编辑“EU”文件,然后通过smallworld再次运行arc文件,使用“
--ignore-conflicts
”标志重新应用文件去重。通常情况下,如果每个区域的文件有所不同,smallworld会为了安全起见,通过错误信息失败。使用“--ignore-conflicts
”会导致它忽略这一点,并仅选择存在的EU版本(默认情况下——见--help
输出中的“--from
”以获取更多信息)。所以如果你这样做,你必须专门编辑“EU”文件,否则它将选择你的文件的旧版本并丢弃新版本!
我在另一个应用程序中编辑了我的区域免费openingTitle.arc
,当我保存时,它突然变大了6倍!帮助! smallworld会让冗余的文件名指向arc文件中完全相同的数据。其他应用程序不会这样做,所以在重新保存时,它们将为每个文件名创建单独的数据副本,从而使整体文件大小膨胀。要修复它,首先确保您的编辑在文件的“EU”版本上,然后再次使用“--ignore-conflicts
”标志运行文件。(也请参阅前面的问题。)
为什么它不重命名TPL文件? openingTitle.arc
包含BRLAN文件(动画),一个BRLYT文件(布局),和一个TPL文件(图像)。这些在每一个区域中都有不同的文件名。* 那么为什么smallworld根本不碰TPL呢?
BRLAN和BRLYT文件名在游戏代码中以硬编码的字符串引用,因此需要为每个区域重命名。另一方面,TPL文件名只由BRLYT文件数据引用。因此,不仅不需要重命名,而且实际上很危险,因为这会破坏这个引用,除非BRLYT文件也更新以匹配新的文件名。
这还要求为每个区域存储单独的BRLYT文件,而不是使用一个共享的文件,smallworld需要包含编辑BRLYTs的代码。仅仅不改变TPL文件名就更容易,而且这样也可以完美工作。
(除了US和EU区域,它们恰好使用相同的TPL文件名。)
为什么你用Rust写的? 我想练习,而且这似乎是一个适合尝试的项目。
依赖关系
~7–16MB
~197K SLoC