The modern tickloop used on WindSpigot

[u7th7]

Hello,

I hope whoever is reading this is doing well and is in good spirits.

I just wanted to ask if there are any future plans for the current tickloop that is being used on WindSpigot. Technically, there isn't anything necessarily “wrong” with it, at least from what I have understood from the current tickloop.

Currently, from what I have read, the tickloop is basically a modern backport from 1.14+ or 1.13 (not sure), and it basically runs like any normal tickloop other than the fact that tasks queued through the async handler can be processed on the main thread while the server is waiting for the next tick.

My only concern is the fact that an old PR from PandaSpigot explains this and reverted the tickloop due to the fact that it was missing features and whatnot. So I am just asking if you guys are aware of this, since I have tried looking into it myself. The current implementation seems to work fine from what I can tell, but I’m not sure whether it includes everything that the newer tickloop relies on, especially considering the concerns brought up in the old PandaSpigot PR.

I mainly just wanted to know if this is something you guys are already aware of or if there are any plans to revisit the current implementation in the future.

I hope this gets looked into.

Have a wonderful day.

[u7th7]

But some things I can confirm is that for some reason this tickloop performs way better than the current PandaSpigot tickloop (From atleast what I have seen)

here are some links if you guys are interested:

PandaSpigot Disc. Server Discussion
PR that dropped "Backport Modern Tickloop"

Ryan talking about it (This was related to someone asking for help with tping players causes lag I think)

I think this is related? No clue.
hpfxd/PandaSpigot#88 (comment)

[uRyanxD]

I am the developer/maintainer of Panda.
The issue is that the tick loop in Minecraft version 1.14 and WindSpigot includes a built-in system for scheduling tasks on the main thread, but Wind did not redirect the legacy system to use it. This version is also affected by the bug https://bugs.mojang.com/browse/MC/issues/MC-183518.

Some time ago, I reverted to the version 1.13.2 tick loop system, but I am currently working on the https://github.com/uRyanxD/PandaSpigot/tree/pr/tickloop branch. This branch correctly implements that backport, includes a fix for that vanilla bug, and is based on the final version released by Mojang. I plan to complete this pull request later this week; feel free to use this version once it is ready.

[windcolor-dev]

I’m not following - what exactly is missing/broken?

[uRyanxD]

This is the main issue in this case, but there is also that vanilla bug that causes slowdowns on certain operating systems; that vanilla bug was recently fixed in version 1.20.3.

[uRyanxD]

There are also other minor issues, such as

az() having been changed to use System.nanoTime() and convert it to milliseconds, whereas some of its usages REQUIRE SYSTEM TIME—for example, the timestamp of when an .mca file was last loaded.

I sincerely recommend that you wait for me to finish the appropriate patch, revert the original commits that added your version of the modern tick loop, and replace it with my version based on Panda.

[uRyanxD]

From what I understand, you’re trying to move j over to the modern task processor (IAsyncHandler), but is this actually how it works in modern vanilla?

Moving to the modern vanilla implementation would mean that the tickloop no longer follows 1.8’s behavior of only processing these tasks at the beginning of a new tick. Instead, they could also be processed when there is enough time between ticks.

Is that how modern vanilla handles these tasks as well?

Yes, since version 1.14—when that tick loop was created—that is how it works; they are part of it and are handled by it

If I recall correctly, Mojang changed this in 1.21.9 by adding something called PacketProcessor, which caused several issues recently and forced Paper to make changes to the tick loop to fix them; however, I didn't port those changes because they were unnecessary and problematic.

[kalibrieren]

From what I understand, you’re trying to move j over to the modern task processor (IAsyncHandler), but is this actually how it works in modern vanilla?

Moving to the modern vanilla implementation would mean that the tickloop no longer follows 1.8’s behavior of only processing these tasks at the beginning of a new tick. Instead, they could also be processed when there is enough time between ticks.

Is that how modern vanilla handles these tasks as well?

Yes, since version 1.14—when that tick loop was created—that is how it works; they are part of it and are handled by it

If I recall correctly, Mojang changed this in 1.21.9 by adding something called PacketProcessor, which caused several issues recently and forced Paper to make changes to the tick loop to fix them; however, I didn't port those changes because they were unnecessary and problematic.

👀 processing between ticks seems interesting. Will this also be included with your new patch?

[uRyanxD]

From what I understand, you’re trying to move j over to the modern task processor (IAsyncHandler), but is this actually how it works in modern vanilla?
Moving to the modern vanilla implementation would mean that the tickloop no longer follows 1.8’s behavior of only processing these tasks at the beginning of a new tick. Instead, they could also be processed when there is enough time between ticks.
Is that how modern vanilla handles these tasks as well?

Yes, since version 1.14—when that tick loop was created—that is how it works; they are part of it and are handled by it
If I recall correctly, Mojang changed this in 1.21.9 by adding something called PacketProcessor, which caused several issues recently and forced Paper to make changes to the tick loop to fix them; however, I didn't port those changes because they were unnecessary and problematic.

👀 processing between ticks seems interesting. Will this also be included with your new patch?

Yes, that is an important part of the tickloop system that isn't working because the tickloop's integrated task queue isn't being populated.

[uRyanxD]

@windcolor-dev, so, I've finished my patch.

Here it is: https://github.com/uRyanxD/PandaSpigot/blob/pr/tickloop/patches/server/0104-Backport-modern-tick-loop-system.patch

It works fine for me in my tests.

I believe you can apply it via GitHub instead of doing it manually—by reverting the commits from your version and then applying my patch. Of course, there will likely be conflicts since they are two different forks, but it should still be easier than doing it by hand.

[u7th7]

Thank you. 🫡

[windcolor-dev]

Thank you so much for sharing! I don't think I would have spotted these issues

[kalibrieren]

#173

[u7th7]

Closed this discussion. If anyone needs to reopen the discussion don't hesitate to open it up again.

Updated Tickloop by @uRyanxD