Estados Operacionais da Rede

O Weave Network opera sempre em estados bem definidos, derivados automaticamente das condições da rede através de uma máquina de estados determinística.

Esses estados não são configuráveis manualmente. Eles resultam do equilíbrio entre energia disponível, buffer energético, integridade estrutural e lógica ativa.

O objetivo desse modelo é garantir previsibilidade, segurança e degradação controlada.

Visão Geral dos Estados

Estado	Scheduler	Throughput	Energia Consumida	Descrição
OFFLINE	❌ Bloqueado	0%	Nenhuma	Controller desligado
BOOTING	❌ Bloqueado	0%	Standby apenas	Inicialização após ativação
ONLINE	✅ Ativo	60-100%	Total (standby + transfers)	Operação normal
RECONFIGURING	❌ Bloqueado	0%	Standby apenas	Topologia mudou, aguardando estabilização
BROWNOUT	⚠️ Degradado	0-60%	Standby apenas	Energia baixa, operação crítica
COLLAPSE	❌ Bloqueado	0%	Nenhuma	Buffer zerado, Trama dissipada
REBOOT	❌ Bloqueado	0%	Standby apenas	Recondensação após colapso

Diagrama de Transições

        ┌─────────────┐
        │   OFFLINE   │◄──── Controller desligado
        └──────┬──────┘
               │ Ativar Controller
               ▼
        ┌─────────────┐
        │   BOOTING   │◄──── Aguardando bind de posição/dimensão
        └──────┬──────┘
               │ Posição vinculada
               ▼
        ┌─────────────┐
    ┌──►│   ONLINE    │◄──── Energia >= onlineThreshold (default 80%)
    │   └──────┬──────┘      Topologia estável
    │          │
    │          │ Energia < brownoutThreshold (50%)
    │          ▼
    │   ┌─────────────┐
    │   │  BROWNOUT   │◄──── Energia sustenta apenas contenção
    │   └──────┬──────┘      Throughput degrada 0-60%
    │          │
    │          │ Energia = 0
    │          ▼
    │   ┌─────────────┐
    │   │  COLLAPSE   │◄──── Buffer zerado, Trama dissipada
    │   └──────┬──────┘
    │          │ Energia restaurada
    │          ▼
    │   ┌─────────────┐
    │   │   REBOOT    │◄──── Delay fixo de estabilização
    │   └──────┬──────┘
    │          │ Cooldown completo
    │          ▼
    └──────────┘
               │
               │ Topologia muda (Fiber quebra, etc)
               ▼
        ┌─────────────┐
        │RECONFIGURING│◄──── Delay fixo de segurança (20 ticks)
        └──────┬──────┘
               │ Cooldown completo
               └─────► ONLINE (se energia suficiente)
                  └──► BROWNOUT (se energia baixa)

Estados Detalhados

1. OFFLINE

Condição: Controller desligado (active = false) ou sem level vinculado.

Comportamento:

❌ Nenhuma contenção de Trama
❌ Nenhuma lógica ativa
❌ Nenhuma transferência
❌ Nenhum consumo de energia
❌ Scheduler bloqueado

Transição de saída: OFFLINE → BOOTING quando Controller é ativado.

Uso: Estado padrão quando Controller é colocado no mundo ou desligado intencionalmente.

2. BOOTING

Condição: Controller ativado mas ainda sem posição/dimensão vinculada no Runtime.

Comportamento:

⚙️ Trama está sendo recondensada
❌ Scheduler bloqueado (sem transferências)
⚡ Consumo: standby apenas
🔄 Aguarda primeiro tick de binding

Transição de saída: BOOTING → ONLINE (se energia suficiente) BOOTING → BROWNOUT (se energia < brownoutThreshold) BOOTING → COLLAPSE (se energia = 0)

Duração típica: 1-2 ticks (bind automático no primeiro serverTick)

3. ONLINE

Condição:

Controller ativo
Energia >= onlineThreshold (default 80% do buffer)
Topologia estável (reconfigCooldown = 0)
Não está em reboot (rebootCooldown = 0)

Comportamento:

✅ Scheduler ATIVO
✅ Transferências normais
✅ Regras de Port executadas
⚡ Consumo: standby + custo por transferência
📊 Throughput: 60-100% (baseado em capacityActiveRatio)

Degradação de Throughput (zona ONLINE):

Energia (% buffer)	Throughput Efetivo	Observação
80-100%	100%	Operação ideal
70%	87.5%	Leve degradação
60%	75%	Degradação moderada
50%	60%	Limiar BROWNOUT

Fórmula:

Se ratio >= 0.8: throughput = 100%
Se 0.5 <= ratio < 0.8: throughput = 60% + ((ratio - 0.5) / 0.3) * 40%

Transição de saída: ONLINE → BROWNOUT se energia cai abaixo de 50% ONLINE → RECONFIGURING se topologia muda ONLINE → COLLAPSE se energia = 0

4. RECONFIGURING

Condição: reconfigCooldown > 0 (topologia mudou recentemente)

Causas de Reconfiguração:

🔨 Fiber quebrada
📦 Bloco colocado/removido na rede
🔌 Port registrada/desregistrada
🏗️ Alteração estrutural detectada

Comportamento:

❌ Scheduler BLOQUEADO por segurança
❌ Nenhuma transferência
⚡ Consumo: standby apenas
🔄 Graph está sendo recalculado
⏱️ Cooldown fixo: 20 ticks (1 segundo)

Motivação do Bloqueio: Prevenir transferências inconsistentes durante mudanças topológicas. Exemplo: Porta de origem pode desaparecer mid-transfer.

Transição de saída: Após cooldown completo:

RECONFIGURING → ONLINE (se energia >= onlineThreshold)
RECONFIGURING → BROWNOUT (se energia < onlineThreshold)
RECONFIGURING → COLLAPSE (se energia = 0)

5. BROWNOUT

Condição:

Energia < brownoutThreshold (default 50%)
Energia > 0 (caso contrário seria COLLAPSE)

Comportamento:

⚠️ Scheduler DEGRADADO (ativo mas com penalidade severa)
⚠️ Throughput reduzido progressivamente
❌ Regras de Port desativadas
⚡ Consumo: standby apenas (sem custo de transferência)
💾 Estado interno preservado

Degradação de Throughput (zona BROWNOUT):

Energia (% buffer)	Throughput Efetivo	Observação
50%	60%	Transição ONLINE→BROWNOUT
40%	48%	Degradação severa
30%	36%	Operação crítica
20%	24%	Quase colapso
10%	12%	Transferências mínimas
5%	6%	À beira do colapso
0%	0%	→ COLLAPSE

Fórmula:

throughput = (ratio / 0.5) * 60%

Hysteresis (Prevenção de Oscilação): Quando recuperando de BROWNOUT, a rede não volta para ONLINE até energia atingir onlineThreshold (80%).

Isso previne "flapping" quando energia oscila entre 48-52%.

Exemplo:

Energia cai para 48% → BROWNOUT
Energia sobe para 55% → permanece BROWNOUT (hysteresis)
Energia sobe para 82% → retorna para ONLINE

Transição de saída: BROWNOUT → ONLINE quando energia >= onlineThreshold (80%) BROWNOUT → COLLAPSE quando energia = 0 BROWNOUT → RECONFIGURING se topologia muda

6. COLLAPSE

Condição: energyRatio <= 0.0 (buffer completamente vazio)

Comportamento:

❌ Scheduler BLOQUEADO
❌ Trama dissipada completamente
❌ Nenhuma operação lógica
⚡ Consumo: 0 FE/t
💾 Payloads em trânsito preservados (não há perda de itens/fluidos)

Recuperação: Quando energia externa é aplicada (Flux Networks, gerador adjacente, etc):

COLLAPSE → REBOOT (com delay de estabilização)

Duração: Indefinida até energia ser restaurada externamente.

Observação Importante: COLLAPSE não deleta itens ou fluidos. A rede apenas para de processar transfers. Storages adjacentes às Ports mantém seus conteúdos intactos.

7. REBOOT

Condição: rebootCooldown > 0 (energia restaurada após COLLAPSE)

Comportamento:

⚙️ Trama sendo recondensada
❌ Scheduler BLOQUEADO
⚡ Consumo: standby apenas
⏱️ Cooldown fixo: configurável (default 40 ticks = 2 segundos)

Motivação do Delay: Simula tempo de estabilização da Trama após colapso total. Previne startup instantâneo (realismo lore).

Transição de saída: Após cooldown completo:

REBOOT → ONLINE (se energia >= onlineThreshold)
REBOOT → BROWNOUT (se energia < onlineThreshold)
REBOOT → COLLAPSE (se energia = 0 novamente)

Máquina de Estados (Ordem de Avaliação)

A derivação de estado segue ordem fixa e determinística:

!active? → OFFLINE
!hasBoundPosition? → BOOTING
reconfigCooldown > 0? → RECONFIGURING
energyRatio <= 0? → COLLAPSE
rebootCooldown > 0? → REBOOT
energyRatio < brownoutThreshold? → BROWNOUT
energyRatio < onlineThreshold && wasRecovering? → BROWNOUT (hysteresis)
Caso contrário → ONLINE

Implementação: WeaveStateMachine.derive(StateInput, previousState)

Scheduler: Quando Executa?

O scheduler só executa nos estados que permitem:

Estado	Scheduler Executa?	Throughput
OFFLINE	❌ Não	0%
BOOTING	❌ Não	0%
ONLINE	✅ Sim	60-100%
RECONFIGURING	❌ Não	0%
BROWNOUT	⚠️ Sim (degradado)	0-60%
COLLAPSE	❌ Não	0%
REBOOT	❌ Não	0%

Código:

if (state == ONLINE || state == BROWNOUT) {
    // Scheduler runs with progressive throughput degradation
    double degradation = computeThroughputDegradation(energyRatio, state);
    int effectiveChannels = (int)(channels * degradation);
    WeaveScheduler.tick(graph, effectiveChannels, ...);
}

Energia e Contenção

Buffer de Energia

Todo Controller possui:

energyStored: FE atual no buffer
maxEnergy: capacidade baseada em tier (via WeaveTierStats)

Cálculo de Ratio:

energyRatio = energyStored / (double) maxEnergy

Consumo de Energia

Standby (toda rede):

standbyFe/t = baseFe + (portCount * portCostFe)

Por Transfer (apenas ONLINE/BROWNOUT):

transferCostFe = configurável por payload type

Thresholds Padrão

brownoutThreshold = 0.5 (50% do buffer)
onlineThreshold = 0.8 (80% do buffer)

Configuráveis via WeaveTierStats datapack.

Exemplos de Cenários

Cenário 1: Startup Normal

Controller colocado no mundo → OFFLINE
Player ativa Controller → BOOTING (1 tick)
Runtime bind completo → ONLINE (energia inicial 100%)
Rede opera normalmente

Cenário 2: Quebra de Fiber

Rede em ONLINE, operando normalmente
Player quebra Fiber → RECONFIGURING
Runtime detecta topologia mudou, ativa cooldown (20 ticks)
Após 1 segundo → ONLINE (se energia suficiente)

Cenário 3: Energia Esgotando

Rede em ONLINE (energia 90%)
Consumo contínuo sem reposição
Energia cai para 48% → BROWNOUT (throughput degrada para 57.6%)
Energia cai para 30% → BROWNOUT (throughput degrada para 36%)
Energia cai para 0% → COLLAPSE (scheduler para)

Cenário 4: Recuperação de Collapse

Rede em COLLAPSE (buffer = 0 FE)
Player conecta Flux Point que injeta 5000 FE
Energia restaurada (ratio > 0) → REBOOT (cooldown 40 ticks)
Após 2 segundos → ONLINE (se energia >= 80%)
                   → BROWNOUT (se energia < 80%)

Cenário 5: Hysteresis (Oscilação Prevenida)

Energia = 60% → ONLINE (throughput 75%)
Transfer grande consome energia → 45% → BROWNOUT
Flux Point injeta energia → 55% → permanece BROWNOUT (hysteresis!)
Mais energia injetada → 82% → retorna para ONLINE

Monitoramento de Estado

Debug Wrench

Shift+Click no Controller:

[WN] Controller dump
  state=ONLINE
  blockReason=ok
  reconfigCooldownTicks=0
  rebootCooldownTicks=0
  energyStored=4500
  maxEnergy=5000
  tier=1

Estados Problemáticos

RECONFIGURING prolongado: → Verifique se não há mudanças contínuas na topologia → Exemplo: Piston empurrando Fiber repetidamente

BROWNOUT constante: → Energia insuficiente para demanda → Soluções: adicionar mais geração, reduzir transfers, upgrade tier

COLLAPSE recorrente: → Consumo > geração → Soluções: buffer maior (tier upgrade), mais geração, reduzir carga

Regras de Design

Invariantes

Determinismo: Mesmo input → mesmo estado (sempre)
Sem Manual Override: Estados não são configuráveis pelo player
Safety First: Mudanças topológicas sempre param scheduler
Graceful Degradation: BROWNOUT permite operação crítica
No Data Loss: COLLAPSE não deleta payloads

Filosofia

"A rede deve falhar visivelmente e previsível, nunca silenciosamente."

Estados operacionais fornecem feedback claro ao player:

Energia baixa → throughput cai gradualmente
Buffer zerado → rede para completamente
Topologia muda → pause temporário para segurança

Configuração Avançada

Via WeaveTierStats (Datapack)

{
  "tier": 1,
  "brownoutThreshold": 0.5,
  "onlineThreshold": 0.8,
  "rebootDelayTicks": 40,
  "reconfigDelayTicks": 20
}

Via Server Config (Dev Only)

[weave_network.tuning]
devCapacityActiveRatio = -1.0  # -1 = disabled, 0.0-1.0 = override ratio

Referências de Código

Estado: WeaveOperationalState.java (core/weave)
Máquina de Estados: WeaveStateMachine.java (core/weave)
Runtime: WeaveRuntime.java (impl/minecraft/neoforge/runtime)
Degradação: WeaveRuntime.computeThroughputDegradation()

Visão Geral dos Estados​

Diagrama de Transições​

Estados Detalhados​

1. OFFLINE​

2. BOOTING​

3. ONLINE​

4. RECONFIGURING​

5. BROWNOUT​

6. COLLAPSE​

7. REBOOT​

Máquina de Estados (Ordem de Avaliação)​

Scheduler: Quando Executa?​

Energia e Contenção​

Buffer de Energia​

Consumo de Energia​

Thresholds Padrão​

Exemplos de Cenários​

Cenário 1: Startup Normal​

Cenário 2: Quebra de Fiber​

Cenário 3: Energia Esgotando​

Cenário 4: Recuperação de Collapse​

Cenário 5: Hysteresis (Oscilação Prevenida)​

Monitoramento de Estado​

Debug Wrench​

Estados Problemáticos​

Regras de Design​

Invariantes​

Filosofia​

Configuração Avançada​

Via WeaveTierStats (Datapack)​

Via Server Config (Dev Only)​

Referências de Código​

Veja Também​

Visão Geral dos Estados

Diagrama de Transições

Estados Detalhados

1. OFFLINE

2. BOOTING

3. ONLINE

4. RECONFIGURING

5. BROWNOUT

6. COLLAPSE

7. REBOOT

Máquina de Estados (Ordem de Avaliação)

Scheduler: Quando Executa?

Energia e Contenção

Buffer de Energia

Consumo de Energia

Thresholds Padrão

Exemplos de Cenários

Cenário 1: Startup Normal

Cenário 2: Quebra de Fiber

Cenário 3: Energia Esgotando

Cenário 4: Recuperação de Collapse

Cenário 5: Hysteresis (Oscilação Prevenida)

Monitoramento de Estado

Debug Wrench

Estados Problemáticos

Regras de Design

Invariantes

Filosofia

Configuração Avançada

Via WeaveTierStats (Datapack)

Via Server Config (Dev Only)

Referências de Código

Veja Também