Мир пустоты как кастомное измерение датапаком и пересчёт координат между
мирами с разным масштабом.
Механизм масштаба — тот же, что у Незера: поле coordinate_scale в типе
измерения, а пересчёт при переходе равен делению масштаба источника на
масштаб назначения. Для пустоты нужно ровно 2.0, то есть один блок пустоты
на два блока оверворлда. Проверено на сервере: coord scale overworld=1.0
void=2.0.
Биом сделан своим (delta_void:void), а не переопределением ванильного
minecraft:the_void. Переопределение трогало бы данные Mojang и конфликтовало
с любыми другими датапаками. Отличия от ванильного — только цвета:
sky_color и fog_color в ноль, плюс выключенный туман и вода.
Что потребовалось по дороге, все три ошибки поймал сервер, а не я:
1. У типа измерения в 1.21.8 обязательное поле logical_height. Без него
сервер отказывается стартовать: "No key logical_height".
2. Файл измерения не принимает дискриминатор "type": "minecraft:dimension".
Кодек LevelStem читает поле type как ССЫЛКУ на тип измерения, и мой
дискриминатор уходил в неё как имя типа. Правильно — "type" со значением
delta_void:void.
3. getAllLevels() живёт на MinecraftServer, а не на DedicatedServer, который
отдаёт CraftServer#getHandle(). И dimensionType() в Paper уже разворачивает
Holder, так что .value() там не нужен и ломает компиляцию.
Отдельно: World#getCoordinateScale() в Paper УЖЕ есть, причём реализован
ровно так, как я собрался писать. Для чтения масштаба ядро менять не нужно.
А вот пересчёта координат в API нет ни в Paper, ни в Bukkit: Player#teleport
его не делает, потому что телепорт не портал. Добавлен default-метод
World#convertLocation с той же формулой, что и ванильная, и без изменения Y.
Хорошая новость про отказ сервера: на битый датапак он не стартует, а
падает в safeMode. Тихая загрузка сломанной генерации была бы хуже.
Диагностика частиц всё ещё в CraftWorld, снимается после проверки прицела.
Частицы не долетали дальше 32 блоков, при том что механика способностей бьёт
на 120. Игрок дальше 32 блоков не видел прицела вообще, но удар приходил.
Причина оказалась на стороне сервера, а не клиента. В ServerLevel есть
if (blockPos.closerToCenterThan(pos, longDistance ? 512.0 : 32.0))
где longDistance это параметр alwaysShow. По умолчанию он false, то есть 32
блока. Но Bukkit-API этот флаг не открывает: в CraftWorld.spawnParticle он
захардкожен в false, а параметр force уходит в overrideLimiter. То есть ни
один плагин на Paper не мог отправить частицу дальше 32 блоков.
Само поле alwaysShow сериализуется в ClientboundLevelParticlesPacket, поэтому
клиент со своей стороны отсечку тоже снимает — тем же механизмом, что и
ванильная команда /particle в режиме display.
Что сделано:
1. World#spawnParticleLongDistance(...) — default-метод, а не абстрактный.
Причина: абстрактный метод в интерфейсе World ломает бинарную совместимость
с любой сторонней реализацией. Фолбэк здесь ведёт себя как обычный
spawnParticle, то есть деградация — «слишком короткая дальность», а не
«частиц нет».
2. CraftWorld переопределяет его. Дистанция применяется фильтрацией списка
получателей ДО вызова ServerLevel, а не патчем самого ServerLevel:
sendParticlesSource принимает готовый receivers, поэтому достаточно отсечь
его самим. Ванильная проверка остаётся нетронутой. Это принципиально —
меньше правок в ванильных патчах, меньше риска конфликтов.
3. Конфиг extended-particle-distance перестал быть мёртвым. Раньше он был
объявлен в DeltaConfig и выводился в /delta, но нигде не читался при отправке
частиц, поэтому переключатель не делал ничего. Теперь он работает как
потолок: плагин запрашивает сколько нужно, сервер режет до 128.
extendedParticleDistanceEnabled=false возвращает стоковые 32.
Замер: /delta теперь показывает "extended distance 128.0 blocks" вместо "off".
Добавлен -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10 в start.sh на проде
и зафиксирован в README с замерами, потому что флаги JVM не переносятся
копированием конфигов — при переезде они теряются молча.
Замер, мир 18 МБ, 0 игроков, 100 с простоя:
коммит живые RSS
без флагов 630 МБ 278 МБ 0.99 ГБ
с флагами 389 МБ 274 МБ 0.69 ГБ
Минус 300 МБ RSS без единого ручного GC.
Причина была не в отсутствии Full GC: jcmd GC.run отрабатывает, живые падают
289 -> 248 МБ, но коммит остаётся на 725 МБ. G1 сжимает кучу только когда
свободно выше MaxHeapFreeRatio, а он по умолчанию 70. При 630 МБ коммита
свободно было 56% — ниже порога, и 350 МБ держались вечно.
Паузы Mixed (то, что ест кадр в рантайме) не ухудшились: median 11.0 -> 9.8,
p95 28.3 -> 28.1, max 38.1 -> 28.7 мс. Concurrent-циклов стало больше
(11 -> 18), общий p95 по всем паузам в одном прогоне вырос 126 -> 270 мс —
это замер без игроков, под нагрузкой флаг ещё предстоит перемерить.
DisableExplicitGC оставлен намеренно: он делает System.gc() no-op, и именно
поэтому освобождение сделано флагом, а не вызовом GC. README теперь
описывает профиль как 15-25 игроков с пиком 34, а не 30-40.
worker-threads: -1 means "auto", and auto on 4 cores resolves to ONE worker.
MoonriseCommon.adjustWorkerThreads halves availableProcessors and then, if the
result is <= 4, collapses it further - 4/2=2, and 2<=3 becomes 1. That single
thread generated the spawn region serially.
Measured on zern.cc (4 vCPU, 8 GB), same jar, same flags, cold world vs warm:
before after
cold, overworld 6770ms 2944ms
cold, nether 1368ms 888ms
cold, total 38.5s 24.9s
warm, overworld 1084ms 803ms
warm, total 16.4s 12.2s
gen-parallelism "default" already resolved to true at startup, so it is now
spelled out rather than left to string comparison at boot.
3 workers is deliberately NOT set here. The main thread plus Netty share the
same 4 cores, and going to 3 trades main-thread headroom for generation that
does not happen every tick. That needs a profile, not a guess.
Also recorded the corollary: player-max-concurrent-chunk-generates is a rate
limiter, not an accelerator. Speeding up generation without raising it just
makes the engine faster behind a throttle that was sized for the old speed.
The README still described decoupled sound range as planned and had no
`/delta displaylead`, no mention of the config being writable, and a command
list containing a `/delta reload` that does not exist.
Also corrects two claims that no longer hold:
- the Display tracking clamp is in org.spigotmc.TrackingRange, not
ChunkMap.TrackedEntity. That was a deliberate choice: TrackingRange is
git-tracked Paper source, so the decompiled Minecraft tree stays untouched.
- the new Bukkit methods are default methods, so plugins referencing them keep
working on stock Paper instead of failing with NoSuchMethodError.
0373806e2 and 0817a5706 were pushed but never built, so the server jar was
broken on main. Six compile errors, all in code that had never run:
- ClientboundSoundPacket takes Holder<SoundEvent> in 1.21, not SoundEvent.
- CraftWorld has no getServer(); the vanilla handle does.
- Server has no paperConfigurations()/registryAccess() - Configurations is
reachable through the console, and saveGlobalSection lives on Configurations
(GlobalConfiguration is a ConfigurationPart, i.e. the data, not the writer).
- ServerPlayer.server is private.
DeltaSound pumped delayed packets through BukkitScheduler, which requires a
live Plugin, and Delta as a core has none. It now uses GlobalRegionScheduler
with a null plugin, which exists precisely for core tasks. Delays are counted
in game ticks via Bukkit#getCurrentTick rather than System.nanoTime, so they
no longer stretch under lag. The pump cancels itself once the queue drains.
New DeltaDisplay holds the predictive-teleport policy (lead range, default,
application) and /delta displaylead tunes it. Honest about its scope:
Display#setTeleportDuration is already stock Bukkit, so Delta adds no new API
to plugins and breaks no compatibility - it centralises the policy and reports
it. The position shift itself is done by the plugin, per visual, along that
visual's own trajectory.
DeltaBuild now registers the existing features in the startup banner instead of
printing "no custom features registered". The banner is emitted from a static
initialiser before paper-global.yml is parsed, so the strings describe the
mechanism and point at /delta status for live values rather than printing
defaults as if they were the running configuration.
When converting to components:
- Remove enchantments with levels <= 0
- Remove the item name if it is not valid JSON
- Remove lore entries that are not valid JSON
The chunk system may not be responsive in a shutdown (i.e
watchdog timeout). Therefore, we should avoid interacting
with the chunk system to increase the odds of a graceful
shutdown.
SashegDev
Jason Penilla
Lulu13022002
Spottedleaf
Emil
Shane Freeder
Aeltumn
MCdragonmaster
Strokkur24
Pedro
MC_XiaoHei
Warrior
Moulberry
Esophose
David