Condenser & Strain

Este documento especifica o sistema de Strain (tensão da Trama) e o Weave Condenser (Condensador de Trama). A base existe no código recuperado, mas seus comportamentos ainda precisam de regressão na build atual.

Visão Geral

Strain representa o esforço de contenção da Trama quando a rede está sendo usada intensamente. Não é uma punição mecânica, mas uma consequência natural do throughput alto: quanto mais payloads fluem simultaneamente, mais energia é necessária para manter a Trama estável.

Weave Condenser é um bloco opcional que amortiza Strain e oferece benefícios secundários à rede, sempre com trade-offs energéticos.

Strain — Tensão da Trama

Conceito

Strain é uma métrica de uso real da rede, não capacidade teórica.

Rede ociosa (poucos payloads fluindo) → Strain baixo → Overhead energético mínimo
Rede sob carga (throughput alto) → Strain alto → Overhead energético aumenta
Rede em colapso (BROWNOUT) → Strain visual aumenta (capacidade reduzida pelo capacityActiveRatio)

Filosofia de design:

Strain não pune o jogador por usar a rede
Strain reflete realidade física: contenção intensa exige mais energia
Strain oferece feedback visual claro sobre estado da rede
Condenser amortiza Strain, mas não é obrigatório (player pode resolver com mais geração de energia)

Cálculo de Strain

Métrica base: Throughput médio nos últimos 30 segundos (600 ticks)

// 1. Somar todas as transferências de todos os payloads
totalThroughput = lastTickItemTransfers +
                  lastTickEnergyTransfers +
                  lastTickFluidTransfers +
                  lastTickRedstoneSignalStrength;

// 2. Calcular média móvel dos últimos 600 ticks
avgThroughput = sum(throughput[últimos 600 ticks]) / 600;

// 3. Calcular capacidade máxima teórica da rede
maxThroughput = channelsTotal × (itemRate + energyRate + fluidRate + redstoneRate);

// 4. Strain final (0.0 → 1.0)
rawStrain = avgThroughput / maxThroughput;

// 5. Aplicar redução de Condensers (se houver)
finalStrain = rawStrain × (1 - 0.15 × effectiveCondenserCount);

Observações importantes:

Strain reflete uso REAL, medido tick a tick
Janela de 30 segundos suaviza variações bruscas
Strain considera capacityActiveRatio automaticamente (throughput cai quando energia cai)
Condensers reduzem Strain final (amortização)

Efeito Mecânico: Overhead Energético

Consumo de standby aumenta proporcionalmente ao Strain:

actualStandbyCost = baseStandbyCost × (1 + finalStrain × 0.20)

Tabela de overhead:

Strain	Overhead Energético	Exemplo (base 1000 FE/t)
0% (ociosa)	+0%	1000 FE/t
25%	+5%	1050 FE/t
50%	+10%	1100 FE/t
75%	+15%	1150 FE/t
100% (carga máxima)	+20%	1200 FE/t

Importante:

Overhead aplica-se ao standby total da rede (Controller + Ports + Fibers + Condensers)
Não afeta throughput (payloads não ficam lentos)
Não afeta tempo de reconfiguração
Apenas aumenta custo energético para refletir esforço de contenção

Feedback Visual

Controller & Condensers

Thresholds visuais:

Strain	Visual	Partículas	Descrição
0-20%	Cor natural do tier	Nenhuma	Rede em uso leve
20-50%	Glow suave (amarelo/laranja)	Ocasionais	Rede em uso moderado
50-80%	Glow intenso (laranja/vermelho)	Frequentes	Rede sob carga alta
80-100%	Glow pulsante (vermelho intenso)	Densas e contínuas	Rede em carga máxima

Animação especial (Condenser):

Condensers "absorvem" partículas da Trama (efeito cosmético)
Partículas fluem das Fibers adjacentes para o Condenser
Intensidade aumenta com Strain

Fibers

Opcional (Marco 7 — acabamento visual):

Textura levemente avermelhada quando Strain > 70%
Transição suave de cor (lerp) baseada em Strain

UI do Controller

Barra de Strain:

Posição: Abaixo da barra de energia
Formato: 0-100% com código de cor (verde → amarelo → vermelho)
Tooltip: "Strain: 65% — Network under moderate load (+13% energy cost)"

Analytics (Marco 7):

Gráfico de throughput médio (últimos 10 segundos)
Breakdown por payload (Items, Energy, Fluids, Redstone)

Sinergia com Estados Operacionais

Strain continua sendo calculado em todos os estados ONLINE:

Estado	Strain Tracking?	Comportamento
OFFLINE	❌	Strain = 0% (sem rede ativa)
BOOTING	❌	Strain = 0% (inicializando)
ONLINE	✅	Cálculo normal
RECONFIGURING	✅	Cálculo normal (rede ainda opera)
BROWNOUT	✅	Cálculo normal + sinergia visual
COLLAPSE	❌	Strain reseta para 0%
REBOOT	❌	Strain reseta para 0%

Sinergia com BROWNOUT:

Quando a rede entra em BROWNOUT:

capacityActiveRatio reduz capacidade efetiva (energia baixa)
Throughput cai proporcionalmente (menos payloads processados)
Mas demanda continua alta (máquinas externas ainda tentam transferir)
Strain aumenta visualmente (throughput/capacidade reduzida = ratio maior)
Rede fica avermelhada (feedback visual perfeito de colapso iminente)

Exemplo:

Rede T3 ONLINE com 80% energia:
→ capacityActiveRatio = 0.8
→ Throughput efetivo = 80% do máximo
→ Se demanda = 100%, Strain aparente aumenta
→ Visual: Glow avermelhado + partículas densas = "rede sufocando"

Design: Strain vira indicador visual de saúde da rede (não apenas carga).

Weave Condenser — Condensador de Trama

Conceito

Bloco opcional que condensa a Trama em uma região específica, absorvendo e contendo energia etérea para benefício da rede inteira.

Lore:

Condenser "absorve" a Trama em um raio de 16 blocos
Trama condensada reduz Strain e melhora estabilidade
Múltiplos Condensers próximos competem pela mesma Trama local (eficiência dividida)
Condensação exige energia adicional (trade-off)

Filosofia de design:

Sempre opcional (rede funciona 100% sem Condenser)
Benefícios reais mas não essenciais
Trade-off claro: reduz overhead de Strain, mas aumenta standby
Requer planejamento espacial (espaçamento de 16+ blocos)

Benefícios

1. Strain Reduction (Principal)

Cada Condenser ativo e eficiente reduz Strain global:

finalStrain = rawStrain × (1 - 0.15 × effectiveCondenserCount)

Eficiência por Condenser:

Condensers dividem eficiência quando estão no raio de 16 blocos uns dos outros:

Condensers no raio	Eficiência individual	Total de redução
1 (sozinho)	100%	-15% Strain
2	50% cada	-15% Strain
3	33% cada	-15% Strain
4+	25% cada	-15% Strain

Exemplo prático:

Cenário A: 3 Condensers espaçados (>16 blocos entre si)
Raw Strain: 80%
→ Cada Condenser: 100% eficiência
→ finalStrain = 0.80 × (1 - 0.15×3) = 0.80 × 0.55 = 0.44 (44%)
→ Overhead: 44% × 0.20 = +8.8% consumo (ao invés de +16%)
→ Economia: ~7.2% de energia total

Cenário B: 3 Condensers juntos (<16 blocos)
Raw Strain: 80%
→ Cada Condenser: 33% eficiência (100% / 3)
→ Total efetivo: 1 Condenser equivalente
→ finalStrain = 0.80 × (1 - 0.15×1) = 0.80 × 0.85 = 0.68 (68%)
→ Overhead: 68% × 0.20 = +13.6% consumo
→ Economia: ~2.4% de energia total (ineficiente!)

Conclusão: Espaçamento correto é crítico para eficiência máxima.

2. Buffer Energético Global

Cada Condenser aumenta buffer total da rede:

bonusBuffer = baseBuffer × 0.05 × effectiveCondenserCount

Limite: Máximo 4 Condensers efetivos (+20% buffer total)

Exemplo:

Rede T3 (base buffer: 500k FE)
→ 2 Condensers espaçados: 500k × 1.10 = 550k FE (+10%)
→ 4 Condensers espaçados: 500k × 1.20 = 600k FE (+20%)

Benefício: Maior resistência a picos de consumo, delay maior antes de BROWNOUT.

3. Tempo de Reconfiguração Reduzido

Cada Condenser reduz cooldown de reconfiguração:

reconfigTime = baseReconfigTime × (1 - 0.10 × effectiveCondenserCount)

Limite prático: 4 Condensers (-40% tempo)

Exemplo:

Base: 20 ticks (1 segundo)
→ 1 Condenser: 18 ticks
→ 2 Condensers: 16 ticks
→ 4 Condensers: 12 ticks (limite efetivo)

Benefício: Rede reconecta mais rápido após mudanças topológicas (adicionar/remover blocos).

Trade-off: Custo Energético

Cada Condenser ativo aumenta standby cost:

condenserStandbyCost = portBaseCost × 2.0 × (1 + strain × 0.20)

Custo base: ~2 Ports de standby (dobro de uma Port)

Tabela de custos por tier:

Tier	Port Base	Condenser Base	Condenser (Strain 50%)	Condenser (Strain 100%)
T1	40 FE/t	80 FE/t	88 FE/t	96 FE/t
T2	80 FE/t	160 FE/t	176 FE/t	192 FE/t
T3	160 FE/t	320 FE/t	352 FE/t	384 FE/t
T4	320 FE/t	640 FE/t	704 FE/t	768 FE/t

Design: Condenser custa caro, mas reduz overhead da rede inteira (ROI positivo em redes grandes).

Regras de Topologia

1. Placement e Remoção (Anti-Duping)

Placement (Colocação):

Condenser só pode ser colocado sobre Weave Fiber existente
Quando colocado: Fiber vira Condenser (substitui o bloco no mundo)
Não pode ser colocado em:
- Air (bloco vazio)
- Blocos normais (stone, dirt, etc.)
- Outros blocos do mod (Port, Controller, etc.)
- Nem mesmo com criativo ou commands (previne duping)

Remoção (Removal):

Com Tuning Key (Config mode) + Shift+Right-Click:
- Drop: Condenser item (1x)
- Fiber volta ao lugar (reaparece no mundo como Weave Fiber)
- Remoção não-destrutiva (preserva Fiber)
Quebrar bloco (sem Tuning Key, ou outro método):
- Drop: Condenser item + Fiber item (2 itens)
- Bloco removido completamente
- Player recupera ambos os componentes

Design Philosophy:

Condenser é "upgrade in-place" de Fiber (não adiciona nova Fiber ao mundo)
Previne duping de Fiber (não cria Fiber do nada)
Tuning Key permite remoção estratégica sem perder Fiber no mundo

Exemplo prático:

1. Player tem rede com Fiber:
   Controller → Fiber → Fiber → Port

2. Player quer otimizar (adicionar Condenser):
   - Right-click com Condenser item na Fiber central
   - Fiber vira Condenser no mundo
   - Controller → Fiber → Condenser → Port ✅

3. Player quer remover (com Tuning Key):
   - Shift+Right-click com Tuning Key (Config mode)
   - Drop: Condenser item
   - Fiber reaparece: Controller → Fiber → Fiber → Port ✅

4. Player quebra Condenser (sem Tuning Key):
   - Drop: Condenser item + Fiber item
   - Mundo: Controller → [air] → Port ❌ (rede desconectada!)

2. Continuidade Linear Apenas

Condenser conecta apenas 2 faces opostas (herda topologia da Fiber original):

Eixo de conexão: Determinado pelo facing do bloco
4 faces laterais NÃO conectam (bloqueadas)
Se colocado em cruz de Fibers: desconecta 2 lados

Placement:

NORTH face (facing property) = oposto à direção do jogador (igual Furnace)
Eixo depende de rotação:
- NORTH/SOUTH → conecta NORTH ↔ SOUTH
- EAST/WEST → conecta EAST ↔ WEST
- UP/DOWN → conecta UP ↔ DOWN (se jogador olhar up/down)

Exemplo visual:

Configuração válida (linha reta):
Fiber → Condenser (NORTH-SOUTH axis) → Fiber
  ✅        ✅                            ✅

Configuração inválida (cruz):
        Fiber (NORTH) ❌
              |
Fiber ← Condenser (EAST-WEST axis) → Fiber
              |                          ✅
        Fiber (SOUTH) ❌

Resultado: Apenas EAST ↔ WEST conectam, NORTH/SOUTH desconectam.

Design: Força planejamento intencional (Condenser não é "drop-in replacement" universal).

3. Regra de Eficiência Espacial

Raio de verificação: 16 blocos (Manhattan distance)

Condensers no mesmo raio dividem eficiência total:

efficiency = 1.0f / Math.min(4, condensersInRadius);

Distância recomendada: 32+ blocos entre Condensers (evita overlap de raios)

Design:

Força espaçamento estratégico
Lore: Condenser "absorve Trama local" (múltiplos competem pela mesma fonte)
Incentiva construção distribuída de Condensers ao longo da rede

Verificação no mundo:

Condensers escaneiam raio de 16 blocos a cada 20 ticks
→ Contam outros Condensers ativos
→ Ajustam eficiência individual
→ UI mostra eficiência atual ("Efficiency: 100%" ou "Efficiency: 50% (1 nearby)")

Estados Operacionais

Estado da Rede	Condenser Ativo?	Strain Reduction?	Consome Energia?
OFFLINE	❌	❌	❌
BOOTING	❌	❌	❌
ONLINE	✅	✅	✅
RECONFIGURING	✅	✅	✅
BROWNOUT	✅	✅	✅
COLLAPSE	❌	❌	❌
REBOOT	❌	❌	❌

Observação: Condenser funciona em qualquer rede com Controller + Core energizado (T1-T7).

Configuração (Datapack)

Arquivo: data/weave_network/config/condenser.json

{
  "condenser": {
    "strain_reduction_per_unit": 0.15,
    "buffer_bonus_per_unit": 0.05,
    "reconfig_reduction_per_unit": 0.10,
    "max_effective_units": 4,
    "standby_cost_multiplier": 2.0,
    "efficiency_radius": 16
  },
  "strain": {
    "enabled": true,
    "measurement_window_ticks": 600,
    "max_energy_overhead": 0.20,
    "visual_threshold": 0.20
  }
}

Parâmetros ajustáveis:

Parâmetro	Padrão	Descrição
`strain_reduction_per_unit`	0.15	Redução de Strain por Condenser (15%)
`buffer_bonus_per_unit`	0.05	Aumento de buffer por Condenser (5%)
`reconfig_reduction_per_unit`	0.10	Redução de tempo de reconfig (10%)
`max_effective_units`	4	Limite de Condensers efetivos
`standby_cost_multiplier`	2.0	Custo base do Condenser (2× Port)
`efficiency_radius`	16	Raio de competição entre Condensers
`measurement_window_ticks`	600	Janela de medição de Strain (30s)
`max_energy_overhead`	0.20	Overhead máximo de energia (20%)
`visual_threshold`	0.20	Strain mínimo para efeitos visuais (20%)

Craft

Resultado: 1× Weave Condenser

Materiais (placeholder — definir durante a progressão jogável):

1× Weave Core (qualquer tier)
4× Weave Matrix
2× Redstone Block
2× Quartz Block

Observação: Recipe via Loom ou Crafting Table (a definir).

Casos de Uso

Cenário 1: Early Game (T1-T2)

Situação: Rede pequena (8-12 Ports), uso moderado.

Strain típico: 20-40% (overhead +4-8%)

Condenser?

❌ Não recomendado
Custo de Condenser (80-160 FE/t) > economia de overhead
Melhor investir energia em expandir geração

Cenário 2: Mid Game (T3)

Situação: Rede média (20-30 Ports), uso alto (automação de processamento).

Strain típico: 50-70% (overhead +10-14%)

Condenser?

✅ Recomendado (1-2 unidades)
Reduz Strain para ~35-55% (overhead +7-11%)
Economia: ~3-4% do consumo total
Benefício adicional: +5-10% buffer (amortece picos)

Cenário 3: Late Game (T4 + Singularities)

Situação: Rede grande (50+ Ports), throughput máximo (múltiplos canais ativos).

Strain típico: 80-100% (overhead +16-20%)

Condenser?

✅✅ Altamente recomendado (3-4 unidades espaçadas)
Reduz Strain para ~35-55% (overhead +7-11%)
Economia: ~9-12% do consumo total (milhares de FE/t)
Benefícios:
- +15-20% buffer (previne BROWNOUT)
- -30-40% tempo de reconfig (QoL para mudanças)
- Rede visualmente mais "estável" (menos partículas)

Implementação Técnica

WeaveGraph (core)

public class WeaveGraph {
    // Strain tracking
    private final RingBuffer<Integer> throughputHistory = new RingBuffer<>(600);
    private float currentStrain = 0.0f;
    private int effectiveCondenserCount = 0;

    /**
     * Atualiza strain baseado em throughput médio dos últimos 30s.
     * Chamado a cada tick quando estado = ONLINE, RECONFIGURING ou BROWNOUT.
     */
    public void updateStrain() {
        // 1. Somar todas as transferências
        int totalTransfers = lastTickItemTransfers +
                             lastTickEnergyTransfers +
                             lastTickFluidTransfers +
                             lastTickRedstoneSignalStrength;

        // 2. Adicionar ao histórico (ring buffer de 600 ticks)
        throughputHistory.add(totalTransfers);

        // 3. Calcular média móvel
        int avgThroughput = throughputHistory.average();

        // 4. Calcular capacidade máxima teórica
        int maxThroughput = calculateMaxThroughput();

        // 5. Strain bruto
        float rawStrain = maxThroughput > 0
            ? (float) avgThroughput / maxThroughput
            : 0.0f;

        // 6. Aplicar redução de Condensers
        float strainReduction = effectiveCondenserCount * 0.15f;
        this.currentStrain = Math.max(0, rawStrain * (1 - strainReduction));
    }

    /**
     * Retorna multiplicador de overhead energético baseado em strain.
     * Exemplo: strain 0.5 → retorna 1.10 (10% overhead)
     */
    public float getEnergyOverheadMultiplier() {
        return 1.0f + (currentStrain * 0.20f); // max +20%
    }

    /**
     * Atualiza contagem de Condensers efetivos.
     * Chamado quando topologia muda.
     */
    public void updateCondenserCount(List<WeaveCondenserBlockEntity> condensers) {
        // Calcular eficiência total considerando overlap de raios
        float totalEfficiency = condensers.stream()
            .map(WeaveCondenserBlockEntity::getEfficiency)
            .reduce(0.0f, Float::sum);

        this.effectiveCondenserCount = Math.min(4, (int) totalEfficiency);
    }
}

WeaveCondenserBlockEntity (impl)

public class WeaveCondenserBlockEntity extends WeaveNodeBlockEntity {

    @Override
    public int getStandbyCost() {
        int baseCost = getTier().getPortBaseCost() * 2; // 2× Port
        float strain = getGraph().getCurrentStrain();
        float overhead = 1.0f + (strain * 0.20f);
        return (int) (baseCost * overhead);
    }

    /**
     * Calcula eficiência baseada em Condensers próximos.
     * Retorna 1.0 (100%) se sozinho, 0.5 (50%) se 2 no raio, etc.
     */
    public float getEfficiency() {
        int nearbyCount = countCondensersInRadius(16);
        return 1.0f / Math.min(4, nearbyCount);
    }

    /**
     * Conta Condensers ativos no raio de 16 blocos (Manhattan distance).
     */
    private int countCondensersInRadius(int radius) {
        BlockPos pos = getBlockPos();
        int count = 0;

        for (int x = -radius; x <= radius; x++) {
            for (int y = -radius; y <= radius; y++) {
                for (int z = -radius; z <= radius; z++) {
                    if (Math.abs(x) + Math.abs(y) + Math.abs(z) > radius) continue;

                    BlockPos checkPos = pos.offset(x, y, z);
                    if (checkPos.equals(pos)) continue;

                    if (level.getBlockEntity(checkPos) instanceof WeaveCondenserBlockEntity other) {
                        if (other.isActive()) count++;
                    }
                }
            }
        }

        return count + 1; // +1 = include self
    }

    /**
     * Verifica se Condenser está ativo (rede ONLINE/RECONFIGURING/BROWNOUT).
     */
    public boolean isActive() {
        WeaveGraph graph = getGraph();
        if (graph == null) return false;

        RuntimeState state = WeaveRuntime.getInstance().getState(graph.getUUID());
        return state == RuntimeState.ONLINE ||
               state == RuntimeState.RECONFIGURING ||
               state == RuntimeState.BROWNOUT;
    }
}

WeaveCondenserBlock (impl)

public class WeaveCondenserBlock extends Block {

    public static final DirectionProperty FACING = BlockStateProperties.FACING;

    @Override
    public BlockState getStateForPlacement(BlockPlaceContext context) {
        // FACING = oposto à direção do player (igual Furnace)
        Direction facing = context.getNearestLookingDirection().getOpposite();
        return defaultBlockState().setValue(FACING, facing);
    }

    /**
     * Define quais faces conectam com Fiber.
     * Apenas 2 faces opostas no eixo do FACING conectam.
     */
    @Override
    public boolean canConnectRedstone(BlockState state, BlockGetter level, BlockPos pos, @Nullable Direction direction) {
        if (direction == null) return false;

        Direction facing = state.getValue(FACING);

        // Conecta apenas nas faces opostas do eixo
        return direction == facing || direction == facing.getOpposite();
    }
}

Inventário da implementação recuperada

Capacidade	Estado em setembro de 2026
Bloco, BlockEntity e tracking de Strain no grafo	Implementado; regressão atual pendente.
Overhead energético e integração com o runtime	Implementado; fórmulas precisam ser confrontadas com esta especificação.
Topologia linear, `FACING` e placement	Implementado; cenários de mundo ainda não foram repetidos.
Eficiência espacial e atualização periódica	Implementado; quantidades e distâncias ainda não foram revalidadas.
Benefícios de buffer e redução de reconfiguração	Implementado via datapack; integração pendente de regressão.
Partículas por Strain	Implementado; leitura visual em jogo pendente.
Barra de Strain no Controller	Planejado; não foi encontrada interface de Controller no código atual.
Glow, pulsação e alteração visual das Fibers	Parcial ou planejado; assets existem, mas o comportamento completo descrito historicamente não foi comprovado.

Considerações de Balanceamento

ROI de Condensers

Break-even point: Strain > 60% em redes com 30+ Ports

Exemplo:

Rede T3 com 30 Ports (standby base: ~5000 FE/t)
Strain 70% → Overhead +14% → +700 FE/t

Adicionar 2 Condensers:
→ Custo: 2 × 320 FE/t = 640 FE/t
→ Strain reduzido: 70% → 40% (redução de 30%)
→ Overhead reduzido: +14% → +8% (-6%)
→ Economia: 6% × 5000 = 300 FE/t
→ Custo líquido: 640 - 300 = +340 FE/t

Resultado: Custo líquido positivo, MAS benefícios secundários:
- +10% buffer (prevenção de BROWNOUT)
- -20% reconfig time (QoL)
- Rede visualmente mais estável

Conclusão: Condenser é investimento estratégico, não otimização essencial.

Tuning para Packmakers

Multiplicadores ajustáveis via datapack:

Strain muito punitivo? → Reduzir max_energy_overhead (0.20 → 0.15)
Condenser muito fraco? → Aumentar strain_reduction_per_unit (0.15 → 0.20)
Condenser muito caro? → Reduzir standby_cost_multiplier (2.0 → 1.5)
Redes muito próximas? → Reduzir efficiency_radius (16 → 12)

Filosofia: Valores padrão equilibrados para vanilla, flexíveis para modpacks.

Perguntas Frequentes

Condenser é obrigatório?

Não. Rede funciona 100% sem Condenser. Ele apenas otimiza overhead energético e oferece benefícios secundários.

O que acontece se eu não usar Condenser em uma rede com Strain alto?

Overhead energético aumenta até +20%. Se você tem geração suficiente, não há problema.

Condensers funcionam em qualquer tier?

Sim, desde que a rede tenha Controller + Core energizado (T1-T7).

Posso colocar Condensers em cruz/diagonal?

Não. Condenser só conecta 2 faces opostas (linha reta). Se colocado em cruz, desconecta 2 lados.

Quantos Condensers devo usar?

Depende do tamanho da rede e Strain típico. Regra geral:

Redes pequenas (T1-T2): 0
Redes médias (T3): 1-2
Redes grandes (T4+): 3-4 (espaçados 32+ blocos)

Condenser funciona em BROWNOUT?

Sim. Strain continua sendo calculado em BROWNOUT, e Condenser continua reduzindo overhead.

Visão Geral​

Strain — Tensão da Trama​

Conceito​

Cálculo de Strain​

Efeito Mecânico: Overhead Energético​

Feedback Visual​

Controller & Condensers​

Fibers​

UI do Controller​

Sinergia com Estados Operacionais​

Weave Condenser — Condensador de Trama​

Conceito​

Benefícios​

1. Strain Reduction (Principal)​

2. Buffer Energético Global​

3. Tempo de Reconfiguração Reduzido​

Trade-off: Custo Energético​

Regras de Topologia​

1. Placement e Remoção (Anti-Duping)​

2. Continuidade Linear Apenas​

3. Regra de Eficiência Espacial​

Estados Operacionais​

Configuração (Datapack)​

Craft​

Casos de Uso​

Cenário 1: Early Game (T1-T2)​

Cenário 2: Mid Game (T3)​

Cenário 3: Late Game (T4 + Singularities)​

Implementação Técnica​

WeaveGraph (core)​

WeaveCondenserBlockEntity (impl)​

WeaveCondenserBlock (impl)​

Inventário da implementação recuperada​

Considerações de Balanceamento​

ROI de Condensers​

Tuning para Packmakers​

Perguntas Frequentes​

Condenser é obrigatório?​

O que acontece se eu não usar Condenser em uma rede com Strain alto?​

Condensers funcionam em qualquer tier?​

Posso colocar Condensers em cruz/diagonal?​

Quantos Condensers devo usar?​

Condenser funciona em BROWNOUT?​

Referências​

Visão Geral

Strain — Tensão da Trama

Conceito

Cálculo de Strain

Efeito Mecânico: Overhead Energético

Feedback Visual

Controller & Condensers

Fibers

UI do Controller

Sinergia com Estados Operacionais

Weave Condenser — Condensador de Trama

Conceito

Benefícios

1. Strain Reduction (Principal)

2. Buffer Energético Global

3. Tempo de Reconfiguração Reduzido

Trade-off: Custo Energético

Regras de Topologia

1. Placement e Remoção (Anti-Duping)

2. Continuidade Linear Apenas

3. Regra de Eficiência Espacial

Estados Operacionais

Configuração (Datapack)

Craft

Casos de Uso

Cenário 1: Early Game (T1-T2)

Cenário 2: Mid Game (T3)

Cenário 3: Late Game (T4 + Singularities)

Implementação Técnica

WeaveGraph (core)

WeaveCondenserBlockEntity (impl)

WeaveCondenserBlock (impl)

Inventário da implementação recuperada

Considerações de Balanceamento

ROI de Condensers

Tuning para Packmakers

Perguntas Frequentes

Condenser é obrigatório?

O que acontece se eu não usar Condenser em uma rede com Strain alto?

Condensers funcionam em qualquer tier?

Posso colocar Condensers em cruz/diagonal?

Quantos Condensers devo usar?

Condenser funciona em BROWNOUT?

Referências