关于制作1.10.2基础整合包的一点看法

最近看到一堆人的还在沿用1.7.10的做法有感,打算写一篇这样的教程,仅供参考


最近看到很多人开始涉足1.10.2的整合,1.10.2除了旧有的模组更新以外,还加入了许许多多有趣的创意新模组。但在这过程中我看到了很多戏剧性的,或者说截然相反的观点,所以我认为写这样一篇教程也是非常有必要的。

1. 1.10.2优化不好,很卡,内存被吃干了

是的,我首先承认这一点,相比较1.7.10来说,1.10.2的加载方式决定了它确实比1.7.10占用内存要高很多。原来1.7.10的材质加载是硬编码,而1.8以后改为了json来描述材质,从开发者角度来说,这是大有裨益的,这意味着材质可以更加灵活。其次,这样的加载能够减少一定量的显卡消耗。 但是这样导致了加载时,游戏会在一开始把所有材质模型全部放入内存,导致内存直接爆炸,还加重了CPU的负担。鉴于很多玩家电脑是高显低U小内存(或者低显低U小内存?),所以玩起来,明显感觉比1.7.10卡。

那么就没有法子减缓这个问题么,当然有,只有正确安装几个模组,能在很大程度上减缓这些问题。

  1. 最新版的forge(目前我用的是forge 1.10.2-12.18.3.2254)。此前旧版本forge曾被发现存在一个巨大bug,玩家即使卸载掉区块,所有的tileentity仍旧会被计算。
  2. FoamFix。asie发现minecraft在加载时候会bake两次材质,导致无用的内存占用。现在优化以后,据说内存占用能减少50%以上。
  3. Optifine。老牌优化模组了。之前我在测试The Betweenlands模组的时候发现,在开启快速渲染以后,在交错维度的fps能从原来波动的20帧直接跳转到稳定的60帧(我锁了帧数上限,所以最高多少帧并未测试)。但是Optifine历来和众多模组有冲突,最近就发现,最新版的’MalisisCore’就和Optifine有冲突,导致启动以后客户端崩溃。当然,回滚会上一个版本就不会崩溃了。
  4. BetterFPS。这个模组饱受争议,有的人说安装以后FPS有提升;有的人说毫无用处;还有人说这模组是个玄学模组。但是据3T的测试,他认为这模组有一定的效果。
  5. Surge。这个模组修改了一些原本存在的bug。其次这个模组能够关闭一些材质动画,据作者介绍,这些动画的关闭对于老式CPU来说可以有效减负。除此之外还有一些加载分析报告等实用性的功能。

根据3T本人的说法,他觉得这些模组的优化下,甚至比开1.5.2的包都流畅。开SF3内存占用也不会超过4G。

2. 1.10.2我要装NEI和Waila,这些模组不都入了1.10.2了么

是的,你说的没错,这些模组确实入了1.10.2。但是它们背后存在的故事你可能并不清楚

  1. NEI此前曾在1.8版本更新过一次,此后很长一段时间,它就没再更新过。但是玩家是要查合成表对的啊,模组作者也要写合成表兼容啊。于是林业作者之一,我们的mezz(不是mdzz啊)出马,写了个JEI。JEI在源码上相比较于NEI的优势我就不谈了,如果你学过大学计算机基础这门课,想必你应该知道:一个程序优先考虑的因素就是可读性,其次才是执行性,最后才是优化。 之后JEI以其优良的可读性,良好的接口,以及mezz本人简直堪称完备的文档,迅速成为众多模组支持的工具。JEI的目的很明确,只做合成相关的查询,这对一个普通的玩家来说已经是足够了。过了一段时间,NEI却突然更新了1.10.2,但是社区已经被JEI占领,所以NEI转而走补全的路线,在以JEI为前置的情况下,补全了旧版本除合成查询外的功能。 但是目前在使用NEI过程中出现了莫名合成表不能查的问题,这让人很是恼火。鉴于作为玩家来说,NEI的功能确实可有可无,还是建议删除。

  2. Waila的问题就更不必谈了,作者自动去年和DecoCraft的作者结婚了以后,他的所有工作全部停止。Waila也不管了,一堆bug也没有修,很多方块在显示上会出现材质丢失,甚至显示错误的情况。树倒猢狲散,昔日Waila的附属也纷纷独立。Wawla成为了独立模组,Waila Harvestability转而增加了对Hwyla的兼容。Waila本身的源码被人fork去,修正了bug,做出了个Hwyla。McJty倒是另辟蹊径,做了个The One Probe模组,去年BTM-2.0超会议上我还嘲笑这模组做的真差劲,随后的更新却让我诧异,代码的可读性,借口的良好性,兼容性方面不必多说。信息显示上也是颇具特色,不但具有单纯的文本显示,还能直观的绘制图案。越来越多的模组也添加了对它的支持。诸如最近的ftb整合包,均无一例外添加了这个模组。

啰嗦了这么多,简而言之一句话。大江东去而已,昔日必备模组早已风光不再,不要再沿用旧思维了。