Effectification [Effect Unification]

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

788
Download

Effectification [Effect Unification]

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

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

Key Features

- Discard Effect Tick – Completely replaces source effects with target effects, preventing duplication - Discard Effect Tick – Control how effect strength converts between mods with configurable multipliers - Discard Effect Tick – Maps to secondary effects if a primary target mod is missing - Discard Effect Tick – Just rename effects without changing mechanics (optional) - Discard Effect Tick – Prevent source mod handlers from triggering to avoid overlapping visual effects - Discard 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. No Duplication: All source effects are stored as the target effect internally 2. No Duplication (Bidirectional mode): `entity.hasEffect(source)` → automatically redirects to target → returns true if target exists 3. No Duplication: 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.

- Bleeding: Bleeding, %%MD1%%, %%MD2%%, %%MD3%%, %%MD4%%, %%MD5%%, %%MD6%% → %%MD7%% (with fallbacks)

- Freeze/Chill: Freeze/Chill, %%MD1%%, %%MD2%%, %%MD3%%, %%MD4%% → %%MD5%% / %%MD6%%

- Stun: Stun, %%MD1%%, %%MD2%%, %%MD3%%, %%MD4%%, %%MD5%%, %%MD6%% → %%MD7%%

- Other: Confusion, Knowledge, Sapped, Immolate, Freezing, and more!

- All modids involved: `hexalia, majruszsdifficulty, attributeslib, valoria, turtlecore, more_rpg_classes, relics, runiclib, irons_spellbooks, eidolon, mowziesmobs, simplyswords, ars_nouveau, goety, cataclysm, alexscaves, obscure_api, netherdepthsupgrade, alexsmobs, advs_spells_arts`

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

- Automatic Migration – Unify multiple effects at once: `"*:bleeding*"` matches all bleeding effects from any mod - Automatic Migration – Exclude specific effects from wildcards: `"*:bleeding* !*:bleeding_immunity"` (immunity effects are NOT unified) - Automatic Migration – Define multiple target effects: `"primary, fallback1, fallback2"` - Automatic Migration – Control how effect strength converts between mods - Automatic Migration – Just rename effects without changing mechanics - Automatic Migration – Prevent source mod handlers from triggering - Automatic Migration – Add visual effects from other mods (supports wildcards) - Automatic Migration – Block unwanted side effects (supports wildcards) - Automatic Migration – 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

```toml [[mappings]] sourceEffect = "*:bleeding* !*:bleeding_immunity !*:bleeding_resistance" targetEffect = "majruszsdifficulty:bleeding, attributeslib:bleeding" amplifierMultiplier = 1.0 onlyVisualChange = false unidirectional = false ```

EXCLUDES immunity/resistance effects - 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

```toml [[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

```toml [[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)

```toml [[mappings]] sourceEffect = "cataclysm:stun" targetEffect = "alexscaves:stunned" amplifierMultiplier = 1.0 onlyVisualChange = false unidirectional = true ```

Result - Potion gives `cataclysm:stun` → stored internally as `alexscaves:stunned` - `entity.hasEffect(cataclysm:stun)` → Result (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)

```toml [[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" ```

Result - 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

```toml [[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

ADS