1.17.1 No-tick view distance affects per-player mob spawning

[sxphirus]

Expected behavior

Per-player mob spawning should not be affected by changing the no-tick view distance.

Observed/Actual behavior

Changing the no-tick view distance to high values affects mob spawning

Steps/models to reproduce

I have found this very difficult to reproduce in a test environment as I haven't been able to figure out a method to do it, instead I have tested it on my prod. servers.

The config I used to reproduce this are below, this has worked consistently for me and the issue is present on build 110;

Within these tests, there is a baseline of >>> 16 named zombie piglins

Test with low no-tick vd

view-distance: 3
mob-spawn-range: 3
no-tick-view-distance: 4
despawn-ranges.hard: 48
monsters: 12
ticks-per: 2
per-player-mob-spawns: true

The plugin shows here that clearly mobs are being spawned as the number of hostiles is over 16 (the baseline mentioned above)

Test with high no-tick vd (this is changed with a plugin)

view-distance: 3
mob-spawn-range: 3
no-tick-view-distance: 24
despawn-ranges.hard: 48
monsters: 12
ticks-per: 2
per-player-mob-spawns: true

These two tests were done within the same 10 minute period, over 50 zombie piglins spawned with a low no-tick view distance, and 0 spawned with a high no-tick view distance.

The farm I used for testing is floating at the height limit in the nether, there are no other spawnable platforms other than the farm within 48 blocks of my player, I can provide a world download for this if needed.

Using commands like worldedit's /butcher 128, or even /butcher 300 kill 0 mobs

Running /butcher 1000 however fixes the issue for around 10 minutes and kills 33 entities. During this time only one player was in / entered the nether, this user was AFK 800 blocks away from my player.

Plugin list

This issue is reproducible with just IHateMobSpawning, ViaBackwards, ViaVersion, ViewDistanceTweaks (tested on a small production server)

This test was completed on a server with more plugins, however, if needed I can send results from either server as they are identical.

Paper version

This server is running Paper version git-Paper-110 (MC: 1.17.1) (Implementing API version 1.17.1-R0.1-SNAPSHOT) (Git: b1cdc12) You are running the latest version Previous version: git-Airplane-44 (MC: 1.17.1)

Agreements

• [X] I am running the latest version of Paper available from https://papermc.io/downloads.
• [X] I have searched for and ensured there isn't already an open issue regarding this.
• [X] My version of Minecraft is supported by Paper.

Other

I have tried to compile this information to the best of my ability, if you need more clarity regarding any parts please let me know! If you are struggling to reproduce the issue I can showcase the issue to you within one of my prod. servers

[JMCY26]

Been having per player mob spawn issues since 1.17 with low rates, I've commented before in other areas that between our 1.16.5 and 1.17 server with the same setup, spawns are drastically lower in 1.17 though didn't have any more information other than that.

Having seen this post, I've gone and reduced our zero tick view distance and sure enough spawns have gone up. Using a spawn mob radius of 4, view distance 5, 0 tick of 11 we struggled for spawns. Reduced 0 tick view distance to 7 and it's proving to be better.

More specifically we've been comparing a drowned mob farm on both servers for weeks and the spawns have been absymal. Especially with more players online, though it looking more consistent now.

[ChiboYen]

I’ve been experiencing this issue as well, was it due to Mojang writing entities to files or something? Or was this an incompatibility by Paper?

[ghost]

To fix the issue I increased tick distance to minimum 5 or 6 and left no tick to 8 Bukkit.yml is on 20 for monsters and per player is on

[sxphirus]

To fix the issue I increased tick distance to minimum 5 or 6 and left no tick to 8 Bukkit.yml is on 20 for monsters and per player is on

Thank you for your response, as outlined in my original post no-tick view distance affects mob spawning when it should not, "Work-arounds" like this should not be required, especially considering on larger servers a tick distance of 5/6 is not viable.

[JMCY26]

Was anything more found about this? Still having really inconsistent mob spawns compared to our 1.16.5 server

[RapidGravy]

Was anything more found about this? Still having really inconsistent mob spawns compared to our 1.16.5 server

I think we're just waiting and hoping for someone to get the time to fix it at this point.

[JMCY26]

Was anything more found about this? Still having really inconsistent mob spawns compared to our 1.16.5 server

I think we're just waiting and hoping for someone to get the time to fix it at this point.

Makes sense, thanks

[swim709]

Was anything more found about this? Still having really inconsistent mob spawns compared to our 1.16.5 server

I think we're just waiting and hoping for someone to get the time to fix it at this point.

Makes sense, thanks

On the Paper discord, somebody suggested to me making the hard despawn range at least a chunk lower than the view distance. I haven't been able to verify if this helps yet, but worth a try.

[JMCY26]

Was anything more found about this? Still having really inconsistent mob spawns compared to our 1.16.5 server

I think we're just waiting and hoping for someone to get the time to fix it at this point.

Makes sense, thanks

On the Paper discord, somebody suggested to me making the hard despawn range at least a chunk lower than the view distance. I haven't been able to verify if this helps yet, but worth a try.

That's a standard thing to do anyway, which I've had setup for a long time now, the issues are present with the same configurations between our 1.16.5 and 1.17 world, the spawns aren't reliable in 1.17 with per player.

[BlueScreenBuddy]

To fix the issue I increased tick distance to minimum 5 or 6 and left no tick to 8 Bukkit.yml is on 20 for monsters and per player is on

Could you perhaps dumb this down for an idiot like me? Which exact tick option and which config? Ty!

[ghost]

Hi everyone I found the solution !!!!!!!!! You have to put no tick at 8 tick a 4 and spawn range in spigot.yml to 3. Add per player in paper! Bukkit .yml monster at 20

[sxphirus]

Hi everyone I found the solution !!!!!!!!! You have to put no tick at 8 tick a 4 and spawn range in spigot.yml to 3. Add per player in paper! Bukkit .yml monster at 20

Thank you for your response, as outlined in my original post no-tick view distance affects mob spawning when it should not, your comment here pretty much repeats what I discussed in the original post.

"Work-arounds" like this should not be required, and such a proper fix should be implemented. I will check to see if this issue is still present on the latest build tonight.

[electronicboy]

We know this is still an issue, mojang changed the entity system so more than likely entities which should have been counted still are applying against the limit, this does extend into the fact that most servers have their despawn ranges misconfigured which is why this behavior is much more visible to some than others

[BlueScreenBuddy]

Hi everyone I found the solution !!!!!!!!! You have to put no tick at 8 tick a 4 and spawn range in spigot.yml to 3. Add per player in paper! Bukkit .yml monster at 20

Thank you for your response, as outlined in my original post no-tick view distance affects mob spawning when it should not, your comment here pretty much repeats what I discussed in the original post.

"Work-arounds" like this should not be required, and such a proper fix should be implemented. I will check to see if this issue is still present on the latest build tonight.

We heard you the first time. We don't need you to tell us workarounds like this shouldn't be required but here we are. Until a long term fix is in place, a short term fix such as those are welcomed. We're not going to sit around with our thumbs up our bums while our users can't enjoy minecraft. We're going to implement these workarounds.

[sxphirus]

this is fixed at commit #6574