超时网格广播

服务器使用 LagGridBroadcaster 插件来播报超时网格给所有玩家.

超时指网格耗时过大, 目前的设定为 1 毫秒(大于等于). 多个网格连接在一起组成子网格将当做一个网格计算.

网格耗时指此网格在一个游戏刻(tick)中, 游戏为了计算此网格上的所有东西而消耗的现实世界时间. 太空工程师 tick rate 为 60t/s, 即每一秒钟服务器将计算全服所有内容 60 次. 因此为了保证服务器流畅运行, 每刻(tick)的总耗时不能超过 16.66 毫秒(ms). 去掉游戏自身的代码, 留给计算服务器内的网格的时间非常捉襟见肘, 通常来说一个耗时达到 1 毫秒的飞船足以对服务器性能产生严重影响.

出于阻止恶意卡服, 并鼓励其他玩家讨伐恶意卡服者的目的, 服务器将在每次测算(目前测算时间间隔为 15 分钟)之后公开耗时最高的且其所属者所在阵营的任意一个成员在 1000 米内(小于等于)的至多三个超时网格. 系统会在超时网格处创建一个紫色 GPS, 此 GPS 全服所有当前在线的玩家都能看到.

每次测算结束后, 插件会在聊天栏私聊每个玩家告知其所在阵营耗时最高的三个网格的耗时, 以及玩家正在操控的(坐在驾驶座上)网格的耗时. 若阵营内的网格耗时已经较高, 请及时整改以免被广播.

网格耗时与网格上的方块数量无关, 与 PCU 也无关, 只与网格上的所有内容(包括但不限于钻头, 组装机, 精炼厂, 物流系统, 电池等)需要消耗多少服务器计算力有关.

为了减少网格耗时, 请避免一些常见的会导致高耗时的情景:

  • 在飞船内部加压. 气密性计算会使游戏在网格出现方块变动时重新计算气密性, 在方块变动频繁时较为卡服. 如果不是非常必要, 请不要使用内部加压的飞船, 尽可能使用宇航服来维持人物气压.
  • 大量的体素变动. 例如巨大的钻头阵列, 如果不是非常必要, 请用小一些的矿机.
  • 机械式部件互相套接. 机械式部件包括活塞, 转子, 铰链等. 当出现活塞套活塞套活塞套活塞的情况时, 很可能产生"鬼畜". 鬼畜是游戏本身的一类 bug, 表现为末端的活塞不受控抖动或多个套接的活塞就像橡胶一样扭动. 鬼畜发生时将非常卡服.
  • 多个网格通过对接口连接在一起而且都开启了推进器和惯性抑制器. 由于游戏特性, 接在一起的对接口也是可以扭动的, 这样接在一起的网格组很可能出现一边为了抵消某一方向的速度而推进了一下导致另一边推进过头, 继而另一边也推进一下, 反过去推进过头, 构成一个无限回馈系统最终网格组像橡胶一样扭动并发生鬼畜.
  • 循环物流系统. 当一个需要从箱子里拉取材料的设备开始拉取材料时, 它会向系统发出拉取申请, 系统会执行一次寻路算法(Pathfinding Algorithm). 如果整个物流系统中存在很多环路(回路, 环), 就会耗费大量计算时间. 为了避免循环物流, 物流系统在设计时应当尽可能保证每一个设备只有一条通路连接到所需拉取/推送材料/成品的方块. 简单地说, 整条船的物流网络应该从前通到末尾, 而不应该像贪吃蛇一样吃自己尾巴. 详见有向无环图在箱子阵列中的应用.
  • 分拣器. 所有方块拉取/推送物品的速度与经过的物流通路无关, 只与方块自身的定义有关. 分拣器并不会增加物流传输速度, 相反的, 分拣器自身的分拣速度可能会降低物流速度. 同时, 分拣器也会导致物流网络耗时大幅度上升. 除了必要场景(一艘船通过对接口从另一艘船主动吸取物资)之外, 其他任何地方都不应该使用分拣器.
  • 氢氧生成器. 虽然氢氧生成器和精炼厂/组装机是一个原理, 但是氢氧生成器产生气体的速度非常快, 远远快于组装机生产零件的频率. 这导致氢氧生成器在事实上等于一个工作速度极其快的组装机. 氢氧生成器会在每一秒疯狂申请物流系统运输, 相当卡服. 一个大型的由众多氢氧生成器, 氢气罐, 氢气推进器组成的系统会显著卡住服务器.
  • 大量的武器. 大量的武器同时开火时服务器为了计算数量繁多的炮弹和导弹将耗费较多的资源. 请尽可能使用效果好的武器, 移除鸡肋的武器.
  • 工坊下载的脚本. 毫不留情地说, 工坊脚本的作者中绝大部分人根本不会写代码, 这些脚本经常使用非常奇葩的手段来完成一件非常简单的工作, 白白浪费了巨量的服务器计算时间. 为了避免深受工坊脚本其害, 请尽可能自己编写脚本.
  • 大量使用某些耗时较高的模组方块, 例如纳米机.

单位换算:

1000ns = 1µs, 1000µs=1ms, 1000ms=1s

国际单位制中英文对照表:

nanoseconds(ns): 纳秒

microsecond(µs): 微秒

millisecond(ms): 毫秒

second(s): 秒