Paper: Awkward random block ticking behaviour

[KennyTV]

What behaviour is expected:

Random block ticking to be (at least mostly) similar to Vanilla's, as seen here:
https://streamable.com/2dxu2b

What behaviour is observed:

Updates only happen in large batches and in very irregular intervals, as seen here (especially at the end when looking at two separate platforms):
https://streamable.com/dlibba

With the normal tickspeed of 3, players complained about grass not spreading at all (-> delayed _quite a while_ until suddenly a bunch appear)

Plugin list:

Via, ProtocolLib, BlockDebug (doesn't have any event listeners/unrelated)

Paper build number:

194

[wizjany]

Believe this is what leaf meant in the description of https://github.com/PaperMC/Paper/pull/2914 ?

[KennyTV]

Hmm yeah, it's a bit too vanilla behaviour breaking imo (if there are a number of chunks with a lot of tickable blocks, someone somewhere with a single block may wait a long time before its their turn, as at least somewhat seen in the second vid - that becomes considerably worse with more and more players and chunks)

[Brokkonaut]

I can confirm this issue. A config option to turn this optimization off would be useful, because its somewhat breaking vanilla behaviour

[aikar]

You can't "Rely" on "random" in vanilla. So it's not breaking any vanilla contracts.

It's a visual difference yes.

@Spottedleaf can we get rid of bias on chunks and make it still distribute a bit more randomly which chunks are selected?

[Brokkonaut]

Just "random" does not say everything, there are a lot of different possible random distributions. Vanilla is near to white noise while the new behavior is definitely different from that.

[Spottedleaf]

We can't get rid of biasing chunks based on how many ticking blocks they have. If we do, we break from vanilla.

When writing this patch I was aware of the difference at high random tick speeds, and decided that compromising on the implementation was not worth it given only insane people are going to run high random tick speeds on their server.

[Brokkonaut]

We have a random tick speed of 3 on our server. Thats the default..

[Spottedleaf]

I'm not talking to you. The videos in this issue are due to high random tick speeds.

Until you can provide videos that showcase different behaviour at tickspeed 3 I don't care. I tested a variety of situations - grass, farming, farm moisturizing and none showed a significant difference on tickspeed 3.
It turns out that the distribution of random ticks over a single tick isn't important when you're dealing with thousands of ticks.

[Brokkonaut]

Paper 196:
https://www.youtube.com/watch?v=R2LNPuPSrJw
Paper 102 (or Spigot or Vanilla):
https://www.youtube.com/watch?v=SN9vNiZL0HY

[aikar]

It's a visual difference yes, but behaviorally looks to be decaying about the same rate....

While I agree it would be ideal if we could maintain a better spread, i don't think it's worth complicating the implementation to support for a cosmetic difference.

Now if leaf can find a way to keep it more distributed, then by all means, but i don't know about an off switch for this in general.

[KennyTV]

This isn't "visual"... as said, the more chunks there are to tick, the longer you have to wait for your own turn, which may take considerably longer than just the few minutes in this video if you have more and more loaded chunks and players. It's not about the amount of blocks changed, but the very long, very non-vanilla and certainly not very fun delay in stalling at 0 change

https://youtu.be/33-0lvz98Tk (YouTube's compression made the initial single blocks invisible, so be sure to forward to the endresult)

Top is Paper, bottom Vanilla with default tickspeed and not sped up, both instances started with the same grass blocks - as seen, wheras all of the origin points in Vanilla have spread a little bit, Paper has only had a small number of batches. A majority of grass blocks have not been spread yet at all (and again, that becomes a lot worse on a larger scale = with more players all waiting for grass spread or w/e in their own different areas).

I don't think an on/off switch is necessary, but it needs to be more evenly distributed

[aikar]

Leafs fix appears to of helped restore normality. Try latest build.