> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nmentities.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Natural Spawns

> Mobs that appear wherever the world suits them, with no spawner placed anywhere.

A natural spawn rule puts mobs wherever the world suits them, rather than at a placed [spawner](spawners). It is the equivalent of MythicMobs' `RandomSpawns`, built here as an **effect type**: a rule is an effect triggered by the world looking right.

Rules live in `Effects/`, and say so with `type: spawn`:

```yaml theme={null}
taiga_alpha:
  type: spawn
  mob: alpha_wolf
  cond: isBiome{taiga, snowy_taiga} && isNight && light <= 7
  rate: 0.8
  pack: 1-3
  max-nearby: 4
  nearby-radius: 48
```

Leave `type:` out and an entry is the [named effect](named-effects) it always was, so nothing you already wrote changes.

## Fields

| Key                 | Also                                 | Default      | What it does                                                                            |
| :------------------ | :----------------------------------- | :----------- | :-------------------------------------------------------------------------------------- |
| `mob`               | `mobname`, `entity`                  | **required** | The mob to spawn.                                                                       |
| `cond`              | `condition`, `if`, `where`           | always       | Where it may spawn — see [conditions](#conditions).                                     |
| `rate`              | `chance`, `probability`, `spawnrate` | `1.0`        | Chance per attempt, 0–1.                                                                |
| `pack`              | `packsize`, `amount`, `group-size`   | `1`          | How many at once. A range, `1-3`.                                                       |
| `level`             | `moblevel`                           | `1`          | The [level](mob-levels) they are tagged with.                                           |
| `replaces`          | `replace`, `instead-of`              | none         | Vanilla entity types this stands in for — see [replacement](#replacing-vanilla-spawns). |
| `suppress-original` | `suppress`, `always-replace`         | `false`      | Cancel the vanilla mob even when this rule does not spawn.                              |
| `effects`           | `lines`, `on-spawn`                  | none         | Effect lines run on each spawned mob, with `@self` bound to it.                         |
| `enabled`           | `on`                                 | `true`       | Whether it starts switched on.                                                          |

Keys are case-insensitive and `-` and `_` are interchangeable.

## Caps

| Key              | Also                            | What it limits                                                           |
| :--------------- | :------------------------------ | :----------------------------------------------------------------------- |
| `max-nearby`     | `density`, `max-per-area`       | How many of this rule's mobs may be within `nearby-radius` of a new one. |
| `nearby-radius`  | `density-radius`, `area-radius` | The radius the above measures over. Default `32`.                        |
| `max-per-chunk`  | `chunk-limit`                   | How many may be alive in one chunk.                                      |
| `max-per-world`  | `world-limit`                   | Total in a world.                                                        |
| `max-per-player` | `player-limit`                  | Total attributed to one player.                                          |

<Warning>
  **`max-per-chunk` is a clumping limit, not a population limit.** A chunk is 16x16, so a rule that suits a whole biome spawns up to that many in *every chunk of it* — it reads like a ceiling and behaves like a density floor. If you have far too many of something, `max-nearby` is almost always the knob you want. The loader warns when `max-per-chunk` is a rule's only cap.
</Warning>

`max-nearby` and `max-per-chunk` are counted **off the mobs actually standing there**, so they hold exactly, restarts included. `max-per-world` and `max-per-player` are counted from what the server has loaded, so they cannot see mobs in chunks nobody has visited this session — treat those two as a brake on runaway spawning rather than exact accounting.

### Server-wide defaults

Any cap a rule does not name falls back to `config.yml`, so you can tune density for a pack of rules somebody else wrote without editing their files:

```yaml theme={null}
natural-spawn:
  caps:
    max-per-chunk: 4
    max-nearby: 0
    nearby-radius: 32
    max-per-world: 0
    max-per-player: 0
```

A rule that names a cap always wins. `0` means no ceiling.

## Conditions

`cond:` is the ordinary effect [condition language](flow-control#conditions), so everything that works in an `if{}` line works here — including any condition an addon registered.

```yaml theme={null}
  cond: isBiome{taiga, snowy_taiga} && isNight && light <= 7 && isGround
  cond: isWorld{world_nether} && y < 40
  cond: isBlockBelow{sand, red_sand} && isSpawnable
```

The place-shaped half of that vocabulary — `isBiome`, `isBlock`, `light`, `y`, `moonphase` and the rest — is listed under [Place conditions](flow-control#place-conditions).

<Note>
  A rule's conditions are evaluated about a **place**, before anything is spawned, so there is no caster. A condition that reaches for one simply never passes here.
</Note>

A rule whose `cond:` cannot be parsed **loads disabled** rather than being skipped, for the same reason a spawner's does: a gate that quietly disappears is worse than no rule at all.

## How the scan works

The scan is anchored to **players**, not to the world: for each player online it tries a handful of candidate points in a shell around them, walking down from near their Y so caves and surface both get looked at.

That means the cost scales with how many people are online, not with world size — an empty server does nothing at all. Chunks are never force-loaded.

```yaml theme={null}
natural-spawn:
  enabled: true
  check-interval: 100     # ticks between passes; 100 = every five seconds
  min-distance: 24        # closer than this and mobs appear in someone's face
  max-distance: 96        # further and nobody would notice it happened
  attempts-per-player: 8  # candidate points per player per pass
```

`attempts-per-player` is the whole cost of the system: raise it for denser spawning, lower it on a busy server. Each rule's own `rate` and caps still apply on top.

## Replacing vanilla spawns

```yaml theme={null}
swamp_slime:
  type: spawn
  mob: acid_slime
  replaces: slime
  suppress-original: true
```

`replaces:` hooks natural vanilla spawning: whenever the server would have spawned one of those, your mob appears instead. `suppress-original: true` means the vanilla mob never appears even when your rule declines.

<Note>
  A rule with `replaces:` is driven by **vanilla spawning alone** and is skipped by the player scan. The two are alternatives, not additions — a rule doing both would spawn twice over from two unrelated clocks. If you want both, that is a rule each.
</Note>

Suppressing a whole vanilla mob type leaves room in the server's own budget for that category, so expect somewhat more of the other mobs in it rather than a quieter world.

## Driving them

[`/nme spawnrule`](spawnrule-commands) — `list`, `info`, `test`, `trigger`, `enable`, `disable`, `reset`. `test` tells you, where you are standing, whether each rule would spawn and why not.

From code, including shipping rules from a world-generator plugin: [Natural Spawns](addon-natural-spawns) in the API section.