DivineMC: Servidores Minecraft Multi-Thread Que Escalam

Certo, você está executando um servidor Minecraft e esbarrou naquela parede. O jar do servidor vanilla não consegue usar seus núcleos de CPU extras, o ticking de chunks acontece em um único thread e o TPS despenca assim que a contagem de jogadores aumenta. Você tentou Paper. Ajustou as configs. E agora?

DivineMC é um fork do Purpur que aproveita a lendária flexibilidade do Purpur e adiciona ticking de chunks paralelo, operações assíncronas e um monte de otimizações bem pensadas. Tem 240 estrelas no GitHub, desenvolvimento ativo e aborda o dimensionamento de forma diferente dos grandes nomes como Folia.

O Que DivineMC Faz

Esta não é uma reescrita completa de threading. DivineMC mantém a arquitetura do Purpur - você tem controle granular sobre taxas de desova de mobs, rastreamento de entidades e ajustes de comportamento diversos. Mas adiciona ticking de chunks regionalizado, o que significa que chunks são processados em paralelo usando seus núcleos de CPU disponíveis em vez de sequencialmente em um único thread.

O projeto também inclui busca de caminho assíncrona, rastreamento de entidades, desova de mobs e envio de chunks. Todas as operações que normalmente bloqueiam o thread principal de tick acontecem fora do thread. Isso significa que quando 50 zumbis fazem busca de caminho em direção a um jogador ao mesmo tempo, isso não derruba seu TPS.

Você também obtém segurança aprimorada (sementes de 1024 bits em vez de 64 bits), suporte para mods de cliente como Syncmatica e Xaero's Map sem infraestrutura de mod no servidor, e cerca de 10 correções de bugs que resolvem várias peculiaridades do Minecraft.

Por Que Você Gostaria Disso

Imagine isto: você está rodando um servidor de sobrevivência para 20-30 jogadores. O servidor está crescendo. O TPS começa a cair durante horas de pico. Você verifica o profiling e metade do seu tempo de tick é carregamento de chunks e cálculos de busca de caminho. Você já fez as otimizações de config padrão do Paper.

Nesse ponto, o ticking de chunks paralelo deixa de ser apenas bacana para se tornar realmente útil. DivineMC permite que chunks façam tick simultaneamente, de forma semelhante ao Folia, mas sem exigir uma migração total ou testes pesados de compatibilidade de plugins.

Também é sólido se você tem múltiplos mundos, um ecossistema denso de plugins ou quando construtores do seu servidor fazem upload de esquemáticos enormes. As operações assíncronas e formatos de arquivo de região melhorados significam melhor estabilidade sob carga pesada.

E isso importa: plugins do DivineMC são 100% compatíveis com Bukkit, Spigot e Paper. Você não fica preso. Se quiser mudar amanhã, todo o seu ecossistema de plugins se move com você.

Como Colocá-lo em Execução

Primeiro, pegue uma build na página de downloads do BX-Team ou MCJars. Escolha o jar que corresponde à sua versão do Minecraft.

Inicialização básica:

java -Xmx4G -Xms2G -jar DivineMC-[version].jar nogui

Ajuste os números `-Xmx` (RAM máximo) e `-Xms` (RAM inicial) com base no seu hardware. Quatro GB é razoável para servidores pequenos a médios. O primeiro lançamento gera seu mundo e arquivos de configuração.

O servidor pedirá que você aceite o EULA. Edite `eula.txt` e mude `false` para `true`, depois reinicie.

Aqui está a parte-chave: DivineMC é tudo sobre configuração. As configurações padrão são sólidas, mas você vai querer ajustar `paper.yml` e configs específicas do DivineMC para sua configuração. Este site de documentação o orienta sobre o que é realmente configurável.

Se você está configurando para jogadores específicos, a ferramenta de criador de whitelist do Minecraft economiza tempo. Cole seus nomes de jogadores e ela gera o formato de whitelist instantaneamente.

Recursos Que Importam

Ticking de Chunks Paralelo processa chunks simultaneamente em vez de um após o outro. Mais blocos atualizando ao mesmo tempo sem o thread principal de tick congelando. Não é mágica, mas é perceptível quando você está sob carga.

Operações Assíncronas movem busca de caminho, rastreamento de entidades, desova de mobs e envio de chunks para fora do thread principal. Isso previne o pico de lag clássico quando uma horda de mobs faz busca de caminho em direção ao seu jogador.

Formato de Arquivo de Região Linear é para armazenamento de mundo - formato antigo V1/V2 ou a nova abordagem Buffered. Otimização de nicho para migrações massivas de mundos ou builds pesadas em esquemáticos. A maioria dos servidores não perceberá, mas está lá se você precisar.

Integração com Sentry envia relatórios de erro para uma instância do Sentry se você configurá-lo. Útil para servidores públicos onde rastreamento estruturado de erros supera cavar através de logs.

Suporte de Protocolo de Mod significa que clientes Syncmatica, Xaero's Map, Jade e Apple Skin funcionam bem sem serem expulsos. Útil se sua comunidade usa mods no lado do cliente.

O Que Pode Tropeçar Você

Ticking de chunks paralelo não é um botão mágico. Você o ativa, mas ainda monitora o desempenho e o ajusta. Não há uma configuração que apenas torne tudo mais rápido.

Se você quer construir a partir do código-fonte (o README inclui comandos gradle), você precisa de um ambiente de desenvolvimento configurado. Para apenas executar um servidor, use os jars pré-construídos. Builds de código-fonte são para contribuidores corrigindo a base de código.

Ticking regional significa que chunks em regiões diferentes são processados em paralelo, mas chunks dentro de uma região ainda fazem tick sequencialmente. Mecanismos de redstone densos em um único chunk ainda vão limitar o TPS desse chunk. A otimização ajuda quando a atividade de construção se espalha por todo o mundo, não concentrada em um único lugar.

Uma coisa rápida: compatibilidade de plugins é com plugins do Bukkit, Spigot e Paper. Não com mods no lado do servidor Forge ou Fabric. Você pode executar mods no lado do cliente o dia todo, mas servidores derivados de vanilla não suportam ambientes de modding no lado do servidor. (É apenas assim que o software de servidor derivado de vanilla funciona.)

Como Se Compara

Folia (também baseado em Paper) aplica multithreading completo ao problema - cada região recebe seu próprio thread e loop de jogo. Paralelização mais agressiva, mas requer testes de plugins mais pesados. DivineMC é menos radical e mantém a flexibilidade do Purpur intacta.

Pufferfish foi pioneiro em alguns dos recursos assíncronos que DivineMC incluiu, mas a manutenção desacelerou. DivineMC parece ser a evolução natural dessa abordagem.

Paper puro é mais simples e muito mais amplamente usado. Pequeno servidor com alguns plugins? Paper provavelmente oferece 90% do benefício com zero overhead de configuração.

Para administradores de servidores confortáveis em ajustar configs e querendo ganhos de desempenho sem interrupção do ecossistema, DivineMC se encaixa bem entre simplicidade e ambição pura.

Obtendo Ajuda Quando Você Precisa

O projeto vive no GitHub. Há um servidor Discord (discord.gg/qNyybSSPm5) onde a comunidade responde perguntas rapidamente. Docs estão em bxteam.org/docs/divinemc.

Se você quer contribuir, há um guia de contribuição. Java, padrões padrão de software de servidor, sistema de build Gradle. Os mantenedores são responsivos e a comunidade é pequena o suficiente para você obter ajuda rapidamente.