▶️ ЗАБЕРИ СВОИ 8 ПОДАРКОВ 🎁 ПРИ СОЗДАНИИ СВОЕГО МАЙНКРАФТ СЕРВЕРА
Моды/Effectification [Effect Unification]
Effectification [Effect Unification]

Effectification [Effect Unification]

A compatibility mod that unifies similar status effects from different mods to prevent duplication and improve cross-mod compatibility.

555
5

Effectification

A compatibility mod that unifies similar status effects from different mods by replacing source effects with target effects, preventing duplication and improving cross-mod compatibility.

Version 2.0.0 – Now with full Fabric support alongside Forge!

Platform Support

  • Fabric – Full support (NEW in 2.0.0!)
  • Forge – Full support
  • 🏗️ Architectury – Cross-platform architecture for seamless compatibility

Key Features

  • Effect Replacement – Completely replaces source effects with target effects, preventing duplication
  • Amplifier Scaling – Control how effect strength converts between mods with configurable multipliers
  • Fallback Support – Maps to secondary effects if a primary target mod is missing
  • Visual-Only Mode – Just rename effects without changing mechanics (optional)
  • Unidirectional Mode – Prevent source mod handlers from triggering to avoid overlapping visual effects
  • Extra Effect Tick – Add visual effects from other mods while keeping target mechanics
  • Discard Effect Tick – Block unwanted side effects while preserving effect detection

How It Works

Status effects work through boolean checks (entity.hasEffect(EFFECT)). Effectification unifies similar effects by:

  1. Unified Storage: All source effects are stored as the target effect internally
  2. Transparent Lookup (Bidirectional mode): entity.hasEffect(source) → automatically redirects to target → returns true if target exists
  3. Single Instance: Only one effect instance exists (the target), but all source variants can detect it (in bidirectional mode)
  4. No Duplication: Multiple bleeding effects from different mods become one unified bleeding effect

Bidirectional vs Unidirectional

Bidirectional (default):

  • Both source and target mod handlers can detect the effect
  • entity.hasEffect(source) → true (redirects to target)
  • entity.hasEffect(target) → true
  • Use when both mods should respond to the effect

Unidirectional:

  • Only target mod handlers can detect the effect
  • entity.hasEffect(source) → false (no redirect)
  • entity.hasEffect(target) → true
  • Prevents source mod handlers from triggering
  • Use to avoid overlapping visual effects (e.g., duplicate screen shake)

Supported Mods (Out-of-the-box)

Note: Pre-configured mappings are included only in the Forge version. Fabric users start with an empty config because most target mods in the default mappings are not available on Fabric. You can add your own mappings for Fabric-compatible mods via the in-game GUI or config file.

Configuration

In-Game GUI (NEW in 2.0.0!)

Configuration GUI

Edit effect mappings directly in-game with the built-in configuration GUI powered by fzzyconfig.

Configuration Files

Main Config: config/effectification/effectification.toml

  • Fully customizable effect mappings
  • TOML format (more readable than JSON)
  • Supports comments
  • Automatic migration from old JSON format

Configuration Features

  • Wildcard Patterns – Unify multiple effects at once: "*:bleeding*" matches all bleeding effects from any mod
  • Exclusions – Exclude specific effects from wildcards: "*:bleeding* !*:bleeding_immunity" (immunity effects are NOT unified)
  • Fallback Chains – Define multiple target effects: "primary, fallback1, fallback2"
  • Amplifier Scaling – Control how effect strength converts between mods
  • Visual-Only Mode – Just rename effects without changing mechanics
  • Unidirectional Mode – Prevent source mod handlers from triggering
  • Extra Effect Tick – Add visual effects from other mods (supports wildcards)
  • Discard Effect Tick – Block unwanted side effects (supports wildcards)
  • Custom Mappings – Add support for any mod utilizing the standard Minecraft effect system
  • Automatic Migration – Config versioning system preserves user changes during updates
Example 1: Wildcard Pattern with Exclusions
[[mappings]]
sourceEffect = "*:bleeding* !*:bleeding_immunity !*:bleeding_resistance"
targetEffect = "majruszsdifficulty:bleeding, attributeslib:bleeding"
amplifierMultiplier = 1.0
onlyVisualChange = false
unidirectional = false

What happens:

  • Unifies ALL bleeding effects from any mod: hexalia:bleeding, relics:bleeding, valoria:bleeding, etc.
  • EXCLUDES immunity/resistance effects: majruszsdifficulty:bleeding_immunity is NOT unified (works normally)
  • One wildcard mapping replaces dozens of individual mappings
  • Safe and efficient - immunity effects remain separate and functional
Example 2: Stun Effect Unification
[[mappings]]
sourceEffect = "cataclysm:stun"
targetEffect = "relics:stun, more_rpg_classes:stun"
amplifierMultiplier = 1.0
onlyVisualChange = false
unidirectional = false

What happens:

  • Potion gives cataclysm:stun → stored internally as relics:stun
  • entity.hasEffect(cataclysm:stun) → true (redirects to relics:stun)
  • entity.hasEffect(relics:stun) → true (actual stored effect)
  • entity.hasEffect(more_rpg_classes:stun) → true (also redirects to relics:stun)
  • All stun variants are unified into one effect instance
  • If Relics is not installed, falls back to more_rpg_classes:stun
Example 3: Bleeding Effect with Fallbacks
[[mappings]]
sourceEffect = "relics:bleeding"
targetEffect = "majruszsdifficulty:bleeding, attributeslib:bleeding, valoria:bleeding"
amplifierMultiplier = 1.0
onlyVisualChange = false
unidirectional = false

What happens:

  • relics:bleeding → stored as first available target
  • Priority: Majrusz's PD → Apothic Attributes → Valoria
  • All bleeding variants (relics:bleeding, hexalia:bleeding, etc.) redirect to the same target
  • Only one effect instance exists, but all variants can detect it
  • Prevents stacking of multiple bleeding effects from different mods
Example 4: Unidirectional Mode (Prevent Overlapping Visuals)
[[mappings]]
sourceEffect = "cataclysm:stun"
targetEffect = "alexscaves:stunned"
amplifierMultiplier = 1.0
onlyVisualChange = false
unidirectional = true

What happens:

  • Potion gives cataclysm:stun → stored internally as alexscaves:stunned
  • entity.hasEffect(cataclysm:stun)false (no redirect!)
  • entity.hasEffect(alexscaves:stunned) → true
  • Cataclysm's handler doesn't trigger (doesn't see the effect)
  • Only AlexsCaves handler triggers (sees the effect)
  • Result: One screen shake instead of two overlapping effects
  • Prevents motion sickness from duplicate visual effects
Example 5: Advanced Stun Unification (Combining All Features)
[[mappings]]
sourceEffect = "*:stun* !*:stun*_resistance !*:stun*_immunity"
targetEffect = "relics:stun, alexscaves:stunned"
amplifierMultiplier = 1.0
onlyVisualChange = false
unidirectional = false
extraApplyEffectTick = "alexscaves:stunned"
discardEffectTick = "*:stun* !*:stun*_immunity !*:stun*_resistance !relics:stun !alexscaves:stunned"

What happens:

  • All stun effects → unified to relics:stun (or alexscaves:stunned if Relics not installed)
  • Bidirectional mode: all mods can detect the stun effect (compatibility)
  • Extra tick: alexscaves:stunned particles and screen shake added
  • Discard pattern: blocks all other stun logic except relics and alexscaves
  • Result: Full compatibility maintained, combined visual effects, controlled behavior
  • Only Relics mechanics + AlexsCaves visuals active, all other stun logic blocked
Example 6: Visual-Only Rename
[[mappings]]
sourceEffect = "some_mod:custom_effect"
targetEffect = "minecraft:regeneration"
amplifierMultiplier = 1.0
onlyVisualChange = true
unidirectional = false

What happens:

  • Effect keeps original mechanics
  • Only display name changes to target effect
  • Amplifier is not converted

Совместимость

Minecraft: Java Edition

1.21.x1.20.x

Платформы

Поддерживаемые окружения

Клиент и сервер

Создатели

Детали

Лицензия:MIT
Опубликован:2 месяца назад
Обновлён:1 неделю назад
Главная