跳转到主要内容

Minecraft 的科普与约定 —— 理世版

Minecraft 是一款“为所欲为”的游戏,但它的运行效率却很差,所以它的流畅需要我们一同维护。
我们也希望玩家们都能或多或少的了解这款游戏,同时了解一点点计算机知识,因此我们设立了这个页面。

为什么这么长,萌新都要哭了   
理世这边的版本没有常见模组物品的卡顿这一章节,请注意。


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


更为详细的介绍与安装教程请查看这里

Java 是一种广泛使用的计算机编程语言,Java 版 Minecraft 是用 Java 编写的,因此游玩 Java 版 Minecraft 需要安装 JRE。

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 性能较弱的电脑上使用。

一般情况下 Minecraft 纯原版的 Java 版本需求如下:

  • 1.0 - 1.11  可以使用 Java 6 和 Java 7,但推荐使用  Java 8。8
  • 1.12(17w13a) - 1.16.5(1.17-21w18a)  需要使用  Java 8。8
  • 1.17(21w19a) - 1.17.1  需要使用  Java 16。16
  • 1.18(1.18-pre2)需要使用  Java 17。17

官方启动器内置 Java 版本为 Java 8-1.8.0_51、Java 16-16.0.1、Java 17-17.0.1
经过测试,使用 Java 17 可以启动 1.0-1.18 纯原版的所有版本,但可能需要添加 JVM 参数  -XX:+CMSIncrementalMode但使用不支持的 1.0Java 等早期版本可能出现导致能放大等可预料的 BUG。BUG,不推荐。

一般情况下 Minecraft 模组环境的 Java 版本需求如下:

  • 运行 1.1 - 1.13  的 Forge、Legacy Fabric 都可以使用 Java 8(81.7 前的某些远古组件可能需要 Java7)。
  • 运行 1.14 - 1.16  的 Forge、Fabric 需要使用  Java 8。8也可以使用 Java9 - Java15 等高版本 Java,但部分模组可能不支持,也有少部分模组需要高版本的 Java。
  • 运行 1.17  的 Forge、Fabric 需要使用  Java 16,16大部分组件也兼容 Java 17。Java17。
  • 运行 1.18+  的 Forge、Fabric 需要使用  Java 17。17

使用高版本 Java 可以在一定程度上提高性能,但有部分模组不支持,同时也可能有模组需要更高版本的 Java。
比如 Paper 服务端已在 Paper 1.16.5 build 669 和之后版本要求使用 Java 16,Paper 团队还建议运行最稳定的最新 JVM(可以理解为更高版本的 Java)。我们推荐尽量在客户端使用高版本的 Java(前提Java,因为即使客户端运算出错也不会影响珍贵的地图(单人游戏兼容性没问题带服务端的)。

推荐使用带下划线的版本进行游戏,使用不支持的 Java 版本可能导致不可预料的 BUG。

如果您的电脑支持,请使用 x6464 版本的 JRE,Java,如果您的系统不是 64 位的,那么我们强烈建议您重装为 64 位系统。


什么是 Tick、TPS、FPS?这分别意味着什么?


几乎所有现代视频游戏(包括 Minecraft)都由一个大循环程序驱动。服务器或客户端的每次执行被称为 Tick(更新)。

每次 Tick(更新),游戏服务器都会执行许多操作,包括:

  • 向所有玩家发送有关服务器上发生的事情的传出数据包(方块改变,实体移动和其他操作)
  • 处理来自玩家的传入数据包(例如,移动,破坏/放置方块,攻击)
  • 生成生物,处理生物AI,寻路等
  • 更新玩家和其他实体的位置
  • 处理模组机器、生物等
  • 处理红石更新
  • 等等

在 Minecraft 中,正常情况下每秒都会执行 20 次 Tick(更新),也就是每秒进行 20 次 GameTick(游戏刻),既 TPS(Ticks Per Second) [每秒Tick数]=20,即每 50 毫秒 Tick 一次,但 TPS 不到 20 时相关处理速度就会变慢导致游戏卡顿,所以 TPS 是一个衡量游戏运行流畅程度的指标。

如果一个 GameTick 所花费的时间少于50毫秒,则服务器将“休眠”剩余的时间,直到准备执行下一个 GameTick 为止。
例如:服务器只花费了 15 毫秒执行一个 GameTick,那么在开始执行下一个 Tick 之前,Tick 循环控制器将会“休眠”(不执行任何操作)35 毫秒。

然而,Minecraft 中所有方块、实体……,甚至是所有 DIM(Dimension) [维度/世界] 的 Tick 操作都是需要依次运行的,也因此,如果要更新的东西过多,或者某个东西更新耗时太长,都会造成一次 GameTick 消耗的时间(MSPT) 超过 50 毫秒。
如果一个 GameTick 执行超过了 50 毫秒,则必须延迟下一个 GameTick 循环周期的执行,那么一秒内就不能执行 20 个 GameTick (游戏刻)也就是说 TPS 低于 20,发生这种情况时,游戏体验会开始变差,因为事情变得不那么敏感且“卡”了。

 

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

注意:各个维度/世界并不是单独运行的,总 MSPT 等于所有维度的 MSPT 之和。也就是说总 TPS 会受到各个维度 MSPT 的影响。各个维度的 TPS 并无太大意义,总 TPS 才是衡量游戏流畅程度的指标。
在 MSPT 小于等于 50 毫秒的时候,Tick 循环控制器会“休眠”到刚好 50 毫秒以保证 TPS 为 20,在 MSPT 超过 50 毫秒的时候,TPS就会降低,此时 TPS 等于 1000 毫秒除以更新耗时毫秒。

 

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

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

 

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

 

你可能还听说过 RedStone Tick(红石刻),正常情况下一个 RedStone Tick 等于 0.1 秒。
例如:红石中继器有 4 个档位,每一个档位是 1 个 RedStone Tick,最小 1 RedStone Tick,最大 4 RedStone Tick。

在 Java 版中,RedStone Tick 实际上不是一个 "真实 "的东西,而是一个由社区创造的术语,因为大多数红石组件的延迟是 2 倍 GameTick,也就是说 TPS 同样会影响红石。

 

在 Minecraft 中还有 Chunk tick(区块刻),Random tick(随机刻),Scheduled tick(计划刻)等,这里就不在叙述了,请自行搜索。


游戏不流畅怎么办?


游戏不流畅有很多情况,TPS低、FPS低,亦或者是网络延迟高等,要分别看待。
如果你不明白这意味着什么,请看上一项。

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

如果遇到了网络不流畅、掉线等,请查看:逐光/理世服务器网络辅助方案
当然,也请同时反馈给我们,这样我们会优化或增加新线路。

如果遇到了网络不流畅可以使用 UU,腾讯,海豚等各类加速器的 虚拟网卡 模式来加速 Minecraft,通常是免费的。
注意一定要使用 虚拟网卡 模式加速,否则加速是无效的,各个加速器的虚拟网卡模式是模式几还请自己尝试。


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


游戏崩溃后,会在 .minecraft 目录中的 crash-reports 文件夹内生成一份崩溃报告。
玩家遇到崩溃以后,如果无法自行解决,请将对应的崩溃报告上传到 Pastebin 类的网站内,之后就可以发送崩溃报告的链接在群里寻求解决方案(当然不一定有解决方案)。此外,能描述在崩溃前做了什么是更好的。
如果截图发出来,简单的错误还好,但复杂问题往往很难诊断。
如果复制粘贴发出来,不仅占位置,还有可能遭到旁人嫌弃。
如果直接发送文件,99%(?)的人并不想下载这些无用文件。

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

怎么看崩溃报告和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


Pastebin 信息短期交换网站的使用


有一些称作 Pastebin 的网站专门提供短期信息交换服务,你可以将文本复制进这些网站然后分享链接给他人,用来发送错误报告等一次性短期文本尤为合适。
这一类型的网站有很多,比较流行的有 pastebin.compaste.eepastebin.centos.orgpaste.ubuntu.com.cnnetcut.cnpaste.ubuntu.com(需要登录)
进入这些网站后将要分享的文本内容复制到网页最大的框中,填写到期时间等相关信息,然后点击 Paste! 或 Create new paste 等按钮,等待页面刷新之后从浏览器的地址栏复制地址,此即为该文本的链接。将该链接分享给他人即可。
注意:这些网站并非永久保存内容,也有一定的泄露风险,请勿分享重要文本。


提问应该注意的问题


请礼貌并完整的提出问题,这样大家才会乐意为你解答。
“我在某某服务器遇到了某某问题,他本来应该是……。可能是某某模组导致的……,请……谢谢

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

  • 要知道,愿意回答问题的人,都是 可爱 的人。
  • 要知道,幼儿园的小朋友都知道要有礼貌。           —— Stop-Ask-Questions-The-Stupid-Ways

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

不要愚蠢地提出问题 【Stop-To-Ask-Questions-The-Stupid-Ways】或 【码云国内加速链接

提问的智慧 【How-To-Ask-Questions-The-Smart-Way】或 【码云国内加速链接


为什么说 Minecraft 是单核游戏


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

Minecraft 的客户端和服务端是分离的,你平时玩的单人游戏其实也分为了服务端和客户端。
当你退出单人游戏时,你是否注意到“正在关闭内置服务端”这一句话,单人游戏也是跑在内置服务端上的
因为同时要运行客户端和服务端,以及客户端的渲染画面等操作往往能很好利用多个核心,因此你运行的“客户端”常常可以利用多个核心。
但为什么我们还是说 Minecraft 是一个单核游戏呢?

Minecraft 中通常有以下几个线程:

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

*还有更多未列举线程,但往往加了线程锁或其他原因,对性能提升帮助极其有限,例如信标计算线程。

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

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


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


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

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

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


Minecraft 原版卡顿的来源与缓解


Minecraft的流畅运行,少不了我们每个人的努力。
这里所写的是简略版本,若欲了解更多请查看:这里

Minecraft 原版卡顿有 2 种来源,客户端卡顿(FPS)与服务端卡顿(TPS)[这里忽略网络]。
*文章中并未列举出所有卡顿来源。
*此处无需优化仅指玩家,而非服务器管理员等。

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

解决方法:不要堆叠过量的这些方块。

 

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

缓解方法:关闭粒子效果,安装优化模组等。

 

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

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

 

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

注意:由于 MC-182868 这个 BUG 在 1.14.4 - 1.16.1 版本中有可能铁轨比红石线卡顿
传递红石信号时,红石信号强度越低卡顿越低(不变化时不卡顿)。
平面传递红石信号时,可以全都替换充能铁轨+观察者的组合,如果你需要持久的信号,那么请不要替换。
斜向传递红石信号时,如果不需要双向信号,可以使用上半砖。如果需要双向信号传递,则不需要替换

 

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

一般情况下无需进行优化。

 

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

通常情况下无需优化,建造飞行器时和地表活塞设施时,可以在机械上方铺一层不透明方块。
但需要保证活塞运动部分无光照,但除非有伪和平,否则很容易刷怪,所以一般无需优化。
因为被活塞推动时,运动中的方块会变成 36 号方块,而 36 号方块是透明方块,这样会造成光照更新。

 

  • 其他红石元件
    所有红石元件都是需要大量计算的,这一点相信不难想象。
    活塞等运动红石元件同时也会在客户端进行运算。

通常情况下无需优化,建造飞行器时和地表活塞设施时,可以在机械上方铺一层不透明方块。
同时保证活塞运动部分无光照,但除非有伪和平,否则容易刷怪,所以一般无需优化。
因为被活塞推动时,运动中的方块会变成 36 号方块,而 36 号方块是透明方块,这样会造成光照更新。

 

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

通常情况下无需优化。

 

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

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

 

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

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


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