You don't set the Cobblemon spawn rate with a single guaranteed "Pokémon per minute" value. pokemonPerChunk influences a local density check, while ticksBetweenSpawnAttempts sets the rhythm of the attempts. Valid positions, biomes, existing creatures and despawn also help decide how many wild creatures your group actually sees.
This guide walks you through a controlled comparison in an existing Cobblemon world. The technical explanations are tied to Cobblemon 1.8.1. First check the mod version that is actually loaded; a pack release and the Minecraft version are different pieces of information. You can find all keys in the complete config reference.
First Clarify What You're Missing
Are there hardly any wild creatures in a certain biome, even though they show up elsewhere? Then you check location, conditions and existing spawns. Does an area fill up slowly? Then you investigate the attempt rhythm. If many creatures stay around a standing player, despawn is relevant too. You investigate a stuttering game separately via RAM and tick performance.
Not every rare creature belongs to the spawn pool of your pack. A desired adventure add-on is not a built-in feature of every Cobblemon installation. Use the data and documentation of the setup you actually chose.

Existing screenshot from the test setup at the time. The image illustrates a landscape; it neither counts all creatures in the radius nor proves your current spawn rate.
How the World Spawner Makes an Attempt
For a player, Cobblemon 1.8.1 selects a zone in the surroundings. The default range is 16 to 64 blocks away from the player; the individual zone is 8 × 16 × 8 blocks in size. Movement direction and available loaded areas influence the selection.
Before new spawn actions are created, the code counts matching Pokémon entities in a 48 × 1000 × 48 block box around the zone center. This is neither a circle of 48 blocks around the player nor a world-wide entity cap. The number is divided by nine and compared with the higher of the current pokemonPerChunk config and the stored spawner value. If it is greater than or equal to that value, the attempt is aborted.
With pokemonPerChunk=1.0, the check therefore kicks in from nine counted entities in this box. This does not imply an absolute maximum of nine in your world: the zone changes, creatures move, and an allowed spawn action can create further entities. Sent-out Pokémon or Pokémon standing in pastures can also contribute with their default-active counting trait. Owned and wild creatures are not generally separated for this density question.
After that, valid positions and matching spawn details must exist. The spawner selects a rarity group and a possible action. If the selection finds no matching action, the pass ends. Eight allowed actions therefore do not mean eight successful spawns.
Which Setting Fits the Question?
| Question | Setting and limit |
|---|---|
| Density | pokemonPerChunk: local density check; not a guaranteed world population |
| Rhythm | ticksBetweenSpawnAttempts: default 20 ticks; stored player spawner value |
| Limit | maximumSpawnsPerPass: default 8; the actual selection may end earlier |
| Zone | spawningZoneDiameter and spawningZoneHeight: influence positions and further checks |
| Proximity | minimumDistanceBetweenEntities: no blanket promise about permanently visible distribution |
| World | worldSpawningBlocklist: check the correct dimension identifier and mod version |
At a stable 20 TPS, 20 ticks correspond to roughly one second. At a lower TPS, the same tick count is not a fixed wall-clock time. Don't turn up density, rhythm and zone size all at once: then you can't attribute a change to a single lever.
Historical Density Measurement: 1.7.3 and 1.8.1
On September 23 and 24, 2026, ten-minute trials ran with a standing protocol test player. Seed, measuring spot, fixed time of day and weather were predefined; vanilla mob spawns were turned off. After the configuration change and reload, the test player rejoined. Samples were counted roughly every 30 seconds.
The following table contains the average of the ten samples from second 300 onward, counted within 96 blocks around the player. It is not a measurement of catching, battling or multiple active fellow players. For the re-measured 1.7.3 values of 0.5 and 3.0, a new instance with the same seed was used.
| Density value | Average: 1.7.3 / 1.8.1 |
|---|---|
| 0.5 | 15.3 / 38.2 |
| 1.0 | 22.8 / 63.0 |
| 2.0 | 44.2 / 88.2 |
| 3.0 | 54.2 / 104.3 |
| 4.0 | 71.9 / 123.4 |
Dots are individual samples, lines connect the averages. Ten samples from one run are not ten independent repetitions. The comparison at a fixed spot does not establish a general spawn or performance promise.
At a value of 1.0, this setup yields 63.0 divided by 22.8, so roughly 2.76 times as many counted creatures. In 1.7.3 the code uses a different measuring box; the theoretical area difference is not automatically the same factor as the observed number. Doubling the config value also does not double the measured amount.

This screenshot is an illustration too. The count values come from the described measurement series, not from the visible image section.
Telling Reload and Reconnecting Apart
Back up config/cobblemon/main.json, check the JSON syntax and initially change only one value. As an authorized administrator, use the reload intended for this:
/cobblemonconfig reload
A successful file reload does not prove that every already existing player spawner adopts its stored value anew. The 1.8.1 source code copies ticksBetweenSpawnAttempts when the player spawner is created. For a changed rhythm, the participating test players therefore reconnect.
Density also uses a stored initial value: the comparison takes the higher value of the current config and the spawner. An increase can therefore take effect in the existing spawner; a decrease needs a newly created spawner. Logging out and back in after the reload makes this difference controllable. Creatures that already exist do not necessarily disappear immediately as a result.
The old short follow-up measurements on rhythm, zone and minimum distance partly contain contradictorily assigned radius counts. We therefore derive no precise factors or guaranteed refill times from them here. Whether the code reads a value live or adopts it on creation is a separate matter. A reliable effect figure needs a suitable new comparison in your specific save.
Rarity Groups Are Not Guaranteed Encounters
In the bundled 1.8.1 spawn resource, the weights common=94.0, uncommon=5.0, rare=0.5, ultra-rare=0.2 and boss=0.3 apply to normal world spawns. The Kotlin class partly contains different initial values; what matters is the resource actually loaded or your external configuration.
These weights describe the group selection. They are not measured chances for a particular species: location, conditions, other influences and empty groups change the result. With the appropriate permission, for example, /checkspawn common shows possible entries at your location. Run the location check as a player; a console does not automatically have this location context.
With exportSpawnConfig=true, an external best-spawner-config.json can be used. Back it up as well. The replaceWithNewVersion switch can lead to replacement when the internal configuration version is higher. An update should therefore explicitly check your own spawn changes.
Despawn: Proximity, Age and Exceptions
Several checks apply to the normal 1.8.1 aging despawner. With the default values, young creatures are initially protected up to 600 ticks; within less than 32 blocks of the nearest player, the age-distance rule does not apply. Further away, the thresholds depend on age and distance. Exactly 32 blocks and "within 32" are therefore not the same code condition.
The historical platform measurement held the player and creature groups fixed. At 20 and 28 blocks, all four animals were still there after 316 seconds. At 40 blocks they vanished between the samples at 120 and 136 seconds; at 56 between 87 and 103, at 72 between 53 and 70 seconds. These are observation intervals, not exact individual lifetimes.
Owner data, persistence, engagement, passenger state and certain held items can trigger other rules. The follow-up measurement confirmed creatures as passengers of a minecart; that is something different from a creature someone is riding. An item handed over via a spawn command does not protect by its name alone: what matters, among other things, is whether the creature can drop it itself. Battles were not played in this bot measurement; the code protection during engagement remains a separate statement.

Your Own Comparison for Your Group
Choose a harmless test area and back up the starting state. Note the pack and mod version, biome, time of day, weather, player count and relevant pastures. First observe the unchanged state over a fixed period. Use the same counting or observation method in the second pass.
Then change exactly one setting, reload and reconnect the test players as described. Keep location and activities comparable. A single random rare spawn is not proof of an increased long-term chance. Repeat the comparison if the variation is large.
Besides the desired game feel, also check tick time, memory and startup behavior. If creatures become too frequent or the group unstable, restore the backed-up value and repeat the same adoption path. Broad delete commands for all Pokémon are not a normal step for your running world.
FAQ
Is pokemonPerChunk the number per visible chunk?
The value controls a local box check around a chosen spawn zone. It is not a guaranteed population per visible chunk and not a world-wide maximum.
Why doesn't the number drop immediately after a reload?
The existing spawner keeps its initial value, and creatures that have already been created initially remain. Reload, reconnect the test players and observe a comparable period.
Will I always get 2.76 times as many Pokémon with 1.8.1?
No. The factor comes from a historical fixed-spot comparison with one test player. Other biomes, packs, player activities and existing creatures change the result.
Does a boss weight of 0.3 mean a fixed alpha chance?
No. Group weight, valid entries and successful selection are different stages. A specific encounter rate was not measured with it.
Do I have to make normal friends operators?
Not for normal play. Config changes and spawn diagnostics are separate permissions. Use the Cobblemon permissions guide and test without OP.
Can I solve every lag problem with fewer spawns?
No. First investigate the actual finding. World generation, other mods, memory, connection or client FPS can also be relevant.
Sources and Test Status
- Cobblemon 1.8.1: density check and spawn actions.
- Player spawner: stored rhythm and zone selection.
- Spawn resource 1.8.1: group weights.
- Aging despawner 1.8.1.
Source code checked and historical density data recalculated on October 7, 2026. The measurements and images date from September; no new Minecraft footage or gameplay trials were carried out for this revision.
Cobblemon: ver exemplo
Gravações próprias de um ambiente de demonstração. A versão e a configuração mostradas podem diferir do teu servidor.
- Bosque de cerejeiras à beira do lago; os Pokémon foram colocados por comando.
- Grupo de Pokémon na encosta (colocado por comando).
- Pokémon lendário sobre o bosque, IA desativada (colocado por comando).
COBBLEVERSE 1.7.42 · Cobblemon 1.7.3 · Minecraft 1.21.1 · 2026-09-23
COBBLEVERSE 1.7.42 · Cobblemon 1.7.3 · Minecraft 1.21.1 · 2026-09-23
COBBLEVERSE 1.7.42 · Cobblemon 1.7.3 · Minecraft 1.21.1 · 2026-09-23