科普与约定

我们希望玩家们都能或多或少的了解这款游戏,同时了解一点点计算机知识,因此我们设立了这个页面。

为什么这么长,萌新都要哭了


什么是 Java ?什么是 JRE ?什么是 OpenJ9?


Java 是一种广泛使用的计算机编程语言,Java 版 Minecraft 是用 Java 编写的(废话)

JRE (Java Runtime Enviromnent) [Java运行时环境] 是运行使用 Java 语言编写的软件的必备环境。
另外还有供开发者使用的 JDK (Java Development Kit) [Java开发套件],JDK 内包含了 JRE。
JVM (Java Virtual Machine) [Java虚拟机] 是 JRE 的一部分,所有 Java 程序都运行在 JVM 中。

因此,我们平时说的安装 Java,其实是安装 JRE。

OpenJ9 是不同于 HotSpot (OpenJDK中的标准JVM) 的一个 JVM,在内存管理方面领先 HotSpot 。经过测试,使用 OpenJ9 能在一定程度上减少 Minecraft 客户端的内存占用,但可能增加 CPU 的使用率,所以不建议在笔记本等 CPU 性能较弱的电脑上使用。

SunJDK,现在已经归为 Oracle 公司所有,也就是现在的 OracleJDK,我们平时装的就是 OracleJDK 构建的 JRE。
OpenJDK 是 SunJDK 在 2006 年末把 Java 开源而形成的项目,并延续至今。

一般情况下运行 Minecraft-Forge,需要使用 Java 8。
运行 1.14+高版本纯净和 FabricMC 可以使用 Java15 等高版本 JAVA(但不保证启动器支持),可以在一定程度上提高性能。

如果您的电脑支持,请使用 x64 版本的 JRE。

我们在群文件中,通常可以看到以下几种 Java8 的 JRE,可以任选一种安装。 
玩模组侧请使用 Java8 的 JRE,如果不想折腾安装 Java8 的 JRE 就可以了。

zulu8.46.0.19-ca-jre8.0.252-win_x64 由 Azul 公司旗下的 Zulu 社区构建的 JRE,在某些任务中,性能略高于 普通OpenJDK 与 OracleJDK。开源。翠鸟计划服务器均使用Zulu JDK。
OpenJDK8U-jre_x64_windows_openj9_8u252b09_openj9-0.20.0 装了 OpenJ9 的 OpenJDK,由 Eclipse 基金会构建维护。开源。
jre-8u251-windows-x64 我们最常见的 OracleJDK,由 Oracle 公司开发。不开源。不想折腾安装这个就对了
zulu8.48.0.53-ca-fx-jre8.0.265-win_x64 装了 OpenJFX 的 Zulu JRE。由于不提供安装程序,所以推荐覆盖到普通的Zulu JRE中。 少部分启动器或模组需要OpenJFX,一般情况下不需要使用。

游玩原版侧时,我们推荐使用高版本 Java ,可以在一定程度上提高性能,群文件中通常有以下几种 JRE,可以任选一种安装。

zulu15.27.17-ca-jre15.0.0-win_x64 由 Azul 公司旗下的 Zulu 社区构建的 JRE,在某些任务中,性能略高于 普通OpenJDK 与 OracleJDK。开源。翠鸟计划服务器均使用Zulu JDK。
zulu15.27.17-ca-fx-jre15.0.0-win_x64 装了 OpenJFX 的 Zulu JRE。由于不提供安装程序,所以推荐覆盖到普通的Zulu JRE中。 少部分启动器或模组需要OpenJFX,一般情况下不需要使用。
OpenJDK15U-jre_x64_windows_openj9_15_36_openj9-0.22.0 装了 OpenJ9 的 OpenJDK,由 Eclipse 基金会构建维护。开源。

游戏不流畅怎么办?什么是 TPS、FPS ?这分别意味着什么?


游戏不流畅有很多情况,TPS低、FPS低,亦或者是网络延迟高等。

在 Minecraft 中,每个实体、可刷新的方块等几乎所有物品在正常情况下每秒都会执行 20 次更新,也就是每秒进行 20 次 GameTick(游戏刻),既 TPS=20。但在红石系统中每次刷新是 0.1 秒.,也就是每秒进行 10 次 ReadstoneTick(红石刻),在红石元件中所有的 Tick 都指 ReadstoneTick(红石刻)。

TPS(Ticks Per Second) [每秒Tick数] 是一个衡量游戏运行流畅程度的指标,决定了世界时间流逝的快慢,正常情况下为 20。

MSPT(Millisecond Per Tick) [毫秒每刻],表示一个 GameTick 平均需要多长时间执行。越低越好。即当前情况下游戏运行一个 GameTick 所花费的毫秒数。MSPT≤50 的时候,TPS = 20(MSPT 不足 50 时,Minecraft 会自动补全到 50)

然而,Minecraft 中所有方块,甚至是所有 DIM(Dimension) [维度/世界] 的更新(Tick) 操作都是需要依次运行的,也因此,如果要更新的东西过多,或者某个东西更新耗时太长,都会造成一次 Tick 消耗的时间(MSPT) 超过50毫秒,如果这一 Tick 的执行时间超过 50 ms,就会导致一秒内不能执行 20 个游戏刻(GameTick),也就是会影响到 TPS,从而导致 TPS 低于 20 影响游戏流畅程度。
注意:各个维度/世界并不是单独运行的,总MSPT等于所有维度的MSPT之和。也就是说总 TPS 会受到各个维度 MSPT 的影响。各个维度的 TPS 并无太大意义,总 TPS 才是衡量游戏流畅程度的指标。
在 MSPT 小于等于 50 毫秒的时候,游戏会自动补齐到刚好 50 毫秒以保证 TPS 为 20,在 MSPT 超过 50 毫秒的时候,TPS就会降低,此时 TPS 等于 1000ms 除以更新耗时ms。

装有 Forge 的情况下使用 /forge tps 会列出所有世界的单独 TPS,Overwall 项是总体 TPS。

在 TPS 很低的情况下,玩家可以感受到其他实体的运动变得缓慢、机器加工时间变长,甚至是吃东西的时间也会变得漫长无比。
但通常情况下 TPS 低并不会影响 FPS。

FPS(Fresh Per Second)[每秒显示帧数],是指客户端游戏画面每秒刷新的次数。如果 FPS 很低,会造成游戏卡顿、操作不流畅,但并不会造成机器加工时间变长等问题。FPS 低是由于玩家电脑配置不足引起的,99%的情况下与服务器并没有关系。

如果遇到了 TPS 低的问题,请反馈至群内,我们将尽力解决。如果遇到了 FPS 低的问题,则应该尝试调整视频设置降低画质,或是尝试装上 Optfine 等客户端优化模组。如果客户端顿卡,可能是由于内存不足引起的。如果内存不足,首先应该尽量多分配内存,如果电脑物理内存不足,可以尝试使用 OpenJ9 降低内存占用。

如果遇到了网络不流畅,可以使用UU,海豚,雷神减速器等各类加速器的 虚拟网卡 模式来加速 Minecraft,通常是免费的。
注意一定要使用 虚拟网卡 模式加速,否则加速是无效的,各个加速器的虚拟网卡模式是模式几还请自己尝试。
当然,也请同时反馈给我们,这样我们会优化或增加新线路。


游戏崩溃了怎么办?怎么发崩溃报告?我该如何获得帮助?


游戏崩溃后,会在 .minecraft 目录中的 crash-reports 文件夹内生成一份崩溃报告。
玩家遇到崩溃以后,如果无法自行解决,请将对应的崩溃报告上传到 paste.ubuntu.compastebin.com 内,如果直接发出来,不仅占位置,还会遭到嫌弃。之后就可以发送崩溃报告的链接在群里寻求解决方案(当然不一定有解决方案)。此外,能描述在崩溃前做了什么是更好的。

希望自己学会看崩溃报告吗?可以尝试阅读 森林蝙蝠 的文章:

怎么看崩溃报告和Timings?【https://www.mcbbs.net/thread-860103-1-1.html
如何查看MC的崩溃报告(1)
https://www.bilibili.com/read/cv26220

如何查看MC的崩溃报告(2)https://www.bilibili.com/read/cv27080
如何查看MC的崩溃报告(3)https://www.bilibili.com/read/cv35870


paste.ubuntu.com 或 pastebin.com 的使用


进入 paste.ubuntu.compastebin.com 将要分享的文本内容复制到网页最大的框中,填写标题和作者,之后点击 Paste! 或 Create new paste。等待页面刷新之后从浏览器的地址栏复制地址,此即为该文本的链接。


提问应该注意的问题


讨论问题请尽量和谐,避免过激的语气。

以下两篇文章是极好的,推荐阅读。

不要愚蠢地提出问题 【Stop-To-Ask-Questions-The-Stupid-Ways

提问的智慧 【How-To-Ask-Questions-The-Smart-Way


为什么说Minecraft是单核游戏


从技术上来说其实 Minecraft 是一个多线程游戏,通常情况下,它至少拥有四个线程(但是有什么用呢)

  • 服务器线程:游戏的主要运算都在这个线程上跑,比如挖矿、合成、机器运行等,客户端也有这样的一个线程,这个线程在90%的程度上决定了你的游戏是否流畅 [你有留意吗,单人世界是跑在内置服务端上的],你的 TPS 就是由这个线程决定的。
  • 渲染线程[Minecraft 1.8+ ]:负责与显卡通讯运行游戏画面渲染。
  • 网络线程[Minecraft 1.8+ ]:负责网络通讯,可能会生成多个线程。
  • 世界生成线程[Minecraft 1.13+ ]:负责运行世界生成器(生成地图)。

没错,几乎所有的运算都是在“服务器线程”上跑的,只有一个线程,意味着只能使用一个核心。
于是我们的 TPS 就被单核性能牢牢定死了,无论你有多少个核心,也都只能围观。
并且主流模组仍然停留在 1.7.10/1.12.2,没有世界生成线程,所以跑图对服务器影响仍然较大。

所以在服务器上,TPS 是一种珍稀资源,能省则省。


UUID是什么?为什么我们需要UUID? 在哪查询UUID?


UUID 是 Universally Unique Identifier(通用唯一识别码)的缩写。

每个 Minecraft 账户都有唯一的 UUID 。例如,Notch 的 UUID 是 069a79f4-44e9-4726-a5be-fca90e38aaf5。
Minecraft 账户的用户名可以更改但 UUID 却永远不会改变。
这使得 Minecraft 服务器能用一种新的方式来追踪玩家确保他们在更改用户名后,玩家在服务器中的信息(如封禁、排名等)仍会保持不变。

查询 UUID 的方式有很多,我们推荐在 https://zh-cn.namemc.com 查询。
如果无法在 https://zh-cn.namemc.com 查询到,可以尝试访问 https://mcuuid.net


原版卡顿的来源与缓解


Minecraft 卡顿有 2 种来源,客户端卡顿(FPS)与服务端卡顿(TPS)[这里忽略网络]。
*文章中并未列举出所有卡顿来源

A.仅影响客户端的卡顿来源
  • 实体与实体渲染的方块
    任何大量的实体和实体渲染的方块都会导致 FPS 下降。
    如:怪物,大量的箱子,栅栏,潜影盒。
    解决方法:不要堆叠过量的这些方块。

  • 粒子效果
    任何大量的粒子效果都会导致 FPS下降。
    如:下雨,TNT爆炸,火焰。
    缓解方法:关闭粒子效果。

B.仅影响服务端的卡顿来源
  • 漏斗
    漏斗具有吸入和传递功能,它每 GameTick 都会更新一次,每 4 GameTick传送一次物品。

根据 ExperimentalIdea 的测试,我们得到了以下数据,测试基于 1.14.4

漏斗上面的方块/状态 使用的MSPT(越低越好)
大箱子 66
普通方块 62.8
空气(什么都不放) 62.6
小箱子 36.5
潜影盒 35.9
32.5
锁住的漏斗(红石充能) 24.3

酿造台

23.5
高炉 23.2
烟熏炉 23
熔炉

22.6

投掷器 22.3
堆肥桶 15.5
红石块(会锁住漏斗) 4.8

可以看到,漏斗上方什么都没有是非常卡顿的,如果你不需要漏斗的吸入物品功能,请在上方放上堆肥桶
如果你想输入物品,可以放上投掷器,把物品放在投掷器中。并尽量少使用大箱子配合漏斗。
还有一个情况就是,如果漏斗指向了一个放满的容器,那么甚至可能会比20个漏斗更卡顿。
向下传输物品可以使用 漏斗→投掷器→漏斗 的方式。
请尽量少使用漏斗矿车,一个漏斗矿车≈60个漏斗的卡顿程度。

横向传递物品:

根据 ExperimentalIdea 的测试,我们得到了以下数据,测试基于 1.15.2

传递物品方式 传输物品时的MSPT(越低越好) 未传输物品时的MSPT(越低越好)
每 8 Tick 触发一次的纯投掷器链
(使用观察者触发)
43.5 35.2

每 12 Tick 触发一次的纯投掷器链
(使用观察者触发)

30.5 24.3
每 16 Tick 触发一次的纯投掷器链
(使用观察者触发)
22.8 18.2
每 24 Tick 触发一次的纯投掷器链
(使用观察者触发)
14.9 11.5
每 32 Tick 触发一次的纯投掷器链
(使用观察者触发)
10.6 8.5
纯漏斗链(上方放置堆肥桶) 9 11.4
每 64 Tick 触发一次的纯投掷器链
(使用观察者触发)
5.2 4.3

传递物品最好使用水流,和气泡柱。
如果要使用漏斗那么最好在上面放置堆肥桶。
如果要使用投掷器链,那么请不要使用太高频率的触发。

 

  • 红石粉
    红石粉强度变化时,会引起周围大量的方块更新,从而造成卡顿。
    在较早版本中, 3 格红石线在信号 0→15 时会引起 144 次更新, 在信号 15→0 时甚至能引起 1782 次更新。
    在最近版本中,1 格红石粉在信号 0→15 时会引起 42 次更新, 在信号 15→0 时甚至能引起 630 次更新。
    在最近版本中,1 格充能铁轨信号改变时会引起 12 次方块更新,1 个中继器在信号改变时会引起 24 次更新。

根据  黑の秋风 的测试,我们得到了一下数据,测试基于 1.14.4
注意:由于 MC-182868 这个 BUG 在1.14.4 - 1.16.1 版本中有可能铁轨比红石线卡顿

测试项目 MSPT(越低越好)
每 8 Tick 更新一次两格相邻的红石线,红石线信号强度为 1 - 2 75
每 8 Tick 更新一次两格相邻的红石线,红石线信号强度为 14-15 239
每 8 Tick 更新一次单格红石线,红石线信号强度为 1 94
每 8 Tick 更新一次单格红石线,红石线信号强度为 15 97
平面信号传递距离 红石线和观察者MSPT
(越低越好)
充能铁轨和观察者MSPT
(越低越好)
9 51 46
8 46 40
7 42 35
6 37 29
5 33 23
4 27 18
3 21 13
2 14 9
1 4 4
斜向45度上升信号传递距离

红石线和实体方块和观察者MSPT
(越低越好)

红石线和上半砖和观察者MSPT
(越低越好)

充能铁轨和实体方块和观察者MSPT
(越低越好)
充能铁轨和上半砖和观察者MSPT
(越低越好)
9 113 30 190 175
8 100 28 156 152
7 93 24 131 138
6 83 22 113 117
5 74 19 93 93
4 63 16 74 70
3 45 14 50 49
2 32 8 30 31
1 7 6 15 15

传递红石信号时,红石信号强度越低卡顿越低(不变化时不卡顿)。
平面传递红石信号时,可以全都替换为充能铁轨+观察者的组合。
斜向传递红石信号时,如果不需要双向信号,可以使用上半砖。如果需要双向信号传递,则不需要替换

 

  • 地狱门
    每次传输物品和实体(你也是实体)时,地狱门都会再次搜索 1600万 个方块找到对应的地狱门,从而造成卡顿
    地狱门只会缓存 15 秒的搜索结果,超过 15 秒后,地狱门会再次搜索。(? - 1.16.1)
    1.16.2 之后机制已改变,只要不是特别大的传送门,几乎不会造成卡顿。

    一般情况下无需进行优化

 

C.同时影响服务端和客户端的卡顿来源
  • 光照
    在白天的时候,会从 255 → 有方块那一层 逐层检测,然后在第一个方块打上 15 级的光照。
    但仅仅会更新一次。

    根据  10935336 的测试,我们得到了一下数据,测试基于 1.16.3
测试项目 MSPT(越低越好)
在 255 层填充 160000 个不透明方块 170
删除在 255 层填充的 160000 个不透明方块 1300
在 0 层 填充 160000 个不透明方块 165
删除在 0 层填充的 160000 个不透明方块 168

通常情况下无需优化,建造飞行器时和地表活塞设施时,可以在机械上方铺一层不透明方块。
因为被活塞推动时,运动中的方块会变成 36 号方块,而 36 号方块是透明方块,这样会造成光照更新。

  • 其他红石元件
    活塞等运动红石元件同时也会在客户端进行运算。

通常情况下无需优化,建造飞行器时和地表活塞设施时,可以在机械上方铺一层不透明方块。
因为被活塞推动时,运动中的方块会变成 36 号方块,而 36 号方块是透明方块,这样会造成光照更新。

  • TNT
    TNT激活后会变为实体并产生大量粒子,导致客户端卡顿。
    TNT爆炸时会计算 1352 条射线,经过一些计算后,射线穿过的地方都会被破坏,需要大量计算,导致服务端卡顿。

通常情况下无需优化

  • 漏斗矿车
    漏斗矿车会吸收比自身稍微大一点范围的方块,且传输速度比漏斗快,导致服务端卡顿。
    漏斗矿车是实体。

请尽量少使用漏斗矿车,一个漏斗矿车≈60个漏斗的卡顿程度。

  • 实体
    实体碰撞需要大量的计算,同时卡客户端与服务端。

不要堆叠实体(相互碰撞),例如矿车,家畜,怪物,掉落物。
不要使用矿车积压方式做刷怪塔。
做牧场请保证有足够的空间,不要牛挤牛,羊挤羊。


Tips:点击页面左边的图书导航来快速查看下一页