Skip to main content

Modded content (MythicMobs / ItemsAdder)

Modded content often shares an underlying vanilla value: a MythicMobs mob can be internally a vanilla pig with a different skin, and an ItemsAdder ore or fish can be internally vanilla iron ore or cod with a custom model. Counting those by their vanilla type would also count them toward the vanilla resource. mythicmobs-types and itemsadder-ids give a resource its own modded id instead, so the two stay separate.

How it works​

Both are read purely through reflection, so neither plugin is a compile or runtime dependency of zCollections. zCollections detects each at startup and logs Hooked into MythicMobs / Hooked into ItemsAdder when found. Neither is required: on a server without them, nothing ever carries a modded id and every resource behaves exactly as targets always did.

The rule once a plugin is hooked: an entity, block, or item carrying a MythicMobs/ItemsAdder id is matched only against resources that list that id. The plain targets vanilla lookup is skipped for it entirely, so a modded mob kill never also counts toward the vanilla resource for its underlying type, whether or not the modded id is registered to any resource of its own.

Modded mobs (MythicMobs)​

hunting:
resources:
pig:
display-name: '&dPig'
material: PORKCHOP
trigger:
type: ENTITY_KILL
targets: [PIG]

modded_pig:
display-name: '&5Corrupted Pig'
material: ROTTEN_FLESH
trigger:
type: ENTITY_KILL
mythicmobs-types: [corrupted_pig]
# locked-icon, unlocked-lore, tiers...

corrupted_pig is the mob's internal MythicMobs type, from your MythicMobs mob file (the id under mobs:), not its display name. Killing a corrupted_pig mythic mob only counts toward modded_pig, even though it is internally an EntityType.PIG; killing a real pig only counts toward pig.

Modded ores, wood, and fish (ItemsAdder)​

mining:
resources:
silver_ore:
display-name: '&fSilver Ore'
material: IRON_ORE
trigger:
type: BLOCK_BREAK
itemsadder-ids: [mymod:silver_ore]
ignore-player-placed: true
# locked-icon, unlocked-lore, tiers...

fishing:
resources:
aether_cod:
display-name: '&bAether Cod'
material: COD
trigger:
type: FISH_CATCH
itemsadder-ids: [mymod:aether_cod]
# locked-icon, unlocked-lore, tiers...

mymod:silver_ore is the item's ItemsAdder namespaced id, exactly as it appears in your ItemsAdder config (namespace:item_id). itemsadder-ids works the same way on BLOCK_BREAK and FISH_CATCH; ignore-player-placed and the other BLOCK_BREAK checks still apply.

Showing the real modded item as the icon​

Add itemsadder: 'namespace:item' next to a resource's material (or a collection's or subcategory's icon, or inside a locked-icon block) and the menu shows that ItemsAdder item, with its custom model, instead of the plain material. The material stays as the fallback for servers without ItemsAdder or for an id ItemsAdder does not know (a warning is logged once). For resource-pack models that do not go through ItemsAdder, custom-model-data: <number> works in the same places. Details on the Categories page.

aether_cod:
display-name: '&bAether Cod'
material: COD
itemsadder: 'mymod:aether_cod'
trigger:
type: FISH_CATCH
itemsadder-ids: [mymod:aether_cod]

Note the two different keys: itemsadder on the resource is the icon, itemsadder-ids in the trigger is what counts.

Adding many modded entries at once​

There is nothing special about "many entries": add as many resources as you want under one collection, each with its own mythicmobs-types or itemsadder-ids. This is how you would expand, say, a Fishing collection with a fish resource per modded dimension, one resource per fish, all inside the same collection.

To keep such a batch tidy, put it in a subcategory: a group inside the collection (Fishing, then Pirate Dimension Fish) that stays greyed out until the player discovers any fish in it, then opens its own menu. Each fish keeps its own progress and tiers.

  • Categories for the full trigger field reference.
  • Anti-exploit for ignore-player-placed and require-fully-grown.