Add hooks for packs that make use of /tick to autocorrect timelib

[Bowswa]

I noticed that you noted that TimeLib has issues with /tick, and realized that would conflict with a mob, in a pack i have an official integration using timelib(requires them do download your pack), which enabled allows seasonal content.

However, we plan to add a mob boss called the "Chronologer", which will make use of /tick to attack you. I was hoping either you could provide simple instructions for packs to automatically trigger an update when they are done making use of /tick... ore:

Add hooks into the pack to SOMEWHAT correct for the time dilation, or otherwise prevent errors while packs are doing as such. For example, my case with the chronologer, i would just want a way to stop timelib from ticking while the attacks are active, and make IRL time dilation a feature as opposed to a bug. From my understanding, i can just run the util/update to fix it.

I understand it may not be your highest priority, just when you get a chance, some official way to properly tell the Lib what to do would be amazing.

[SilicatYT]

Thank you for creating this issue. What you wrote certainly is a problem with TimeLib that, if I get to it, should get fixed.

If you don't mind, I'd like to hear some of your thoughts about how this could be fixed.

First of all, I'd like to note that there is a /tick query command that allows me to see what the current target tick rate is. However, the return value is an integer. This means that if I use that to autocorrect TimeLib, it will be slightly inaccurate if the target tick rate has decimal places (Like 20.5). This inaccuracy would build up over time.

Second, /tick query only detects the target tick rate, meaning it wouldn't be enough to automatically detect offsets created by lag, or usage of /tick sprint/freeze/step.

=> Essentially, if I use the /tick query command, I'd still have to periodically update the time just to make sure there's no offsets. This would require some rewrites for the #timelib:time_updated function tag (which runs whenever the time updates), because updates would now be run way more often, potentially causing issues for datapacks that rely on this tag. Basically this function tag should then only run if the date changed, not if the time was updated.

Another potential solution would be to utilize the world border to detect changes in the tick rate (including lag or /tick sprint). The drawback of this would be that players could easily walk out of the worldborder, which is especially an issue if it's manually set to a smaller size (-> Complete incompatibility).

A third potential solution would just periodically run the timelib:util/update function, also requiring a rewrite for the #timelib:time:updated function tag. This would somewhat fix desyncs by lag as well, but only every so often. Minor short-term desyncs wouldn't be fixed at all.

A fourth potential solution would offer a start and stop function the pack user can run whenever they start manipulating the tick rate, which would then periodically run the update function. Maybe an option could be added that requires the user to specify exactly how long one second lasts now (scaled up so I can have some decimal places).

=> As you can see, this is a rather tricky problem that I don't know the immediate solution for. If you have any thoughts on this, please let me know. In the meantime, you should be fine running the timelib:util/update function every so often (or even every tick, it shouldn't break) to keep the time updated during high or low tick rates, as a sort of band-aid solution.

[Bowswa]

Well the first and quickest thing to do would be again to simply provide hooks to allow other packs to tell TimeLib to stop trying to update & to tell TimeLib to update again. My use case would be just fine for this solution, as desyncing from IRL time would then be a feature instead of a bug. EDIT: Along with this hook, i would add function tags that run every tick, every second, every minute, every hour, every day, and every month, controlled on time update(in a different use case i check every second to make sure the month is still December, as if a world is open when the month turns from december to january, simply using the update function tag wouldnt work.) So when the pack update on start, it runs the update function. When the pack ticks over a month, the monthly functions run(which would include my use case). When the pack ticks over a day, the daily functions run(required for some of my own planned use cases)

But maybe you could implement a couple of the other solutions you said above, but have them disabled by default for most people so as others may want to, they can playtest those features to find the issues of each one and see what works the best.

But i do believe that the stop/start & update option would be a good simpler solution that can be used by DP creators, at least for now.

I think the worldboarder solution is a bad one, given the reason this pack was made, and i think you should eliminate that one off the bat.

There is also adding your own functions to control the /tick command, making the necessary modifications to how the pack perceives time natively in the exact same tick, the downside of that being the work(this solution would also be pretty cool for a mod version, where you could compile the mod yourself with the custom /tick command)

I also think that there might be a combination of the other proposed solutions that may work, but at this time my brain is too tired to think that much.

EDIT: I reference my own use cases as examples of where this lib applies, i know there are more, but i'm providing specific examples that i myself can think of as to how things would work, to at least help visualize some of this stuff.

[Bowswa]

This may end up being an issue that can only be eased, not completely fixed, at least in the latest 1.21.4. The limitations of datapacks are immense.

[SilicatYT]

Thank you for your detailed response. I will look and see what can be done.

Considering I can't fully detect the usage of a tick command (/tick sprint, /tick freeze, /tick step) or lag, I will probably at least try to resolve the issue for "/tick rate ", and then add a start and stop function so you can tell other datapacks that time is inaccurate during that time.