⚡ Motor de desempenho e controle de filas

O Agrarian Reform foi desenvolvido para servidores de alto desempenho, suportando mega-fazendas agrícolas sem congelamentos ou quedas de TPS.

📊 Infobox de desempenho

Property	Value
Global Throttling Budget	`CROPS_PER_TICK = 5`
Queue Implementation	`java.util.concurrent.ConcurrentLinkedQueue`
Sub-Chunk Palette Filter	`hasOnlyAir()` & `maybeHas(AgrarianCropRules::isCropBlock)`
Busca de Água	Anéis concêntricos de Chebyshev ($r=1 \to \text{maxRange}$, saída rápida em água próxima)
Otimização de Calçados	Descarte rápido para pés descalços ($0.0001\mu\text{s}$, sem iterar NBT de encantamentos)
Logs de Diagnóstico	Loggers estáticos SLF4J controlados pela regra temporária `agrarian_reform:debug_mode`

🧠 Design arquitetônico e pipelines de descarte rápido

┌─────────────────────────────────────────────────────────────┐
│                    CHUNK LOAD SCAN EVENT                    │
│ Palette Pre-Filter: section.hasOnlyAir() & maybeHas()       │
│ Rejects 85%+ empty non-crop sub-chunks in O(1) time         │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌──────────────────────────────┴──────────────────────────────┐
│             ConcurrentLinkedQueue<CropUpdateTask>           │
│ Lock-free thread-safe task buffer                           │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌──────────────────────────────┴──────────────────────────────┐
│                  ServerTickEvents.END_SERVER_TICK           │
│ Polls at most 5 tasks per tick                              │
│ Updates block states smoothly across consecutive game ticks │
└─────────────────────────────────────────────────────────────┘

Por que 5 plantações por tick?

Se um jogador descarregar uma fazenda com 10.000 plantações por 24 horas, atualizar todos os 10.000 blocos em um único tick causaria um travamento severo do servidor com mais de 1000 ms de latência.

Distribuindo as atualizações a 5 plantações por tick sem bloqueios:

O servidor mantém 20 TPS constantes durante o carregamento de chunks.
As 10.000 plantações atualizam suavemente ao longo de 2.000 ticks (~100 segundos) em segundo plano sem travamentos.

🏎️ Principais otimizações algorítmicas

Filtro de Paleta de Sub-Chunks: Em vez de verificar $98.304$ blocos por chunk, o CropScanner lê as paletas das seções de $16 \times 16 \times 16$. Se não houver plantações, a seção inteira é ignorada em $0.0001\mu\text{s}$.
Anéis Concêntricos de Chebyshev: A busca por água ocorre de dentro para fora ($r = 1 \to \text{maxRange}$). Como a maioria das plantações possui água vizinha ($r=1$), a verificação termina no primeiro anel.
Descarte Rápido Descalço: Ao pisar na terra arada, o hasSoftStep() verifica primeiro se o calçado está vazio. Se estiver, as consultas a NBT de encantamentos são puladas.
Parada Precoce na Maturidade Máxima: Em loops acelerados, o processo para imediatamente quando a planta atinge a idade máxima, economizando mutações de bloco.

💾 Garantias de zero escrituras em disco

Varreduras de Chunks Somente Leitura: O escaneamento inicial não altera blocos, mantendo o indicador unsaved como false.
Mutação Seletiva de Blocos: No ContinuumManager.processCropUpdate, o level.setBlock() só é chamado quando há avanço real de estágio $\Delta \text{age} > 0$.
Proteção Contra Escrita em Disco: Como os chunks permanecem unsaved == false, o salvamento vanilla ignora a serialização NBT e gravação em disco ($0\text{ I/O de disco}$).

⚡ Motor de desempenho e controle de filas ​

📊 Infobox de desempenho ​

🧠 Design arquitetônico e pipelines de descarte rápido ​

Por que 5 plantações por tick? ​