Make every <timespan> Independent of Server Tick Rate

[PoomsXP]

Suggestion

I propose that every events use real elapsed time rather than a fixed number of Minecraft ticks.

For example:

every 1 second:

should execute once every real-world second regardless of the server's configured or actual tick rate.

Why?

The term "second" implies a real-world second rather than a specific number of game ticks.

Making every use real elapsed time would:

Produce consistent behavior across servers.
Match user expectations.
Prevent timers from speeding up or slowing down when TPS differs from 20.
Make periodic tasks more suitable for cooldowns, statistics, API polling, and other time-sensitive systems.

Other

every 1 second is currently based on 20 ticks.

This means the real-world interval changes when the server's tick rate differs from 20 TPS:

20 TPS → every 1.0 seconds
30 TPS → every ~0.67 seconds
10 TPS → every 2.0 seconds

As a result, the same script can behave differently across servers.

Tick-based scheduling would still be available through explicit tick intervals:

every 20 ticks:

This allows scripts that need game-time precision to continue using ticks while making time units behave according to their literal meaning.

Agreement

• I have read the guidelines above and affirm I am following them with this suggestion.

[skriptlang-automation]

🔍 Triage Checklist

Type

• bug
  • Confirm you can reproduce before continuing
• suggestion
  • Apply relevant classification labels (scripting, syntax, docs, etc.)

Priority

• priority: lowest
• priority: low
• priority: medium
• priority: high
• priority: critical

Project

• 2.15 Releases
• 2.16 Releases

---

• ✅ Mark as triaged

[sovdeeth]

This would be a massive breaking change and a significant change to how Skript schedules tasks, if it is even feasible. Scheduling still has to use the Bukkit scheduler at some point, and that works on a tick-based delay, not a real-time delay.
This would also require us to differentiate between tick timespans and non-tick timespans, which would be another significant breaking change and complicate code paths.

I am strongly against this change.

If a 'wall clock' delay capability is required, I would rather it look more like wait 1 seconds in real time or similar. (This is, of course, assuming reliable scheduling based on wall clock time is actually achievable)

[PoomsXP]

This would be a massive breaking change and a significant change to how Skript schedules tasks, if it is even feasible. Scheduling still has to use the Bukkit scheduler at some point, and that works on a tick-based delay, not a real-time delay. This would also require us to differentiate between tick timespans and non-tick timespans, which would be another significant breaking change and complicate code paths.

I am strongly against this change.

If a 'wall clock' delay capability is required, I would rather it look more like wait 1 seconds in real time or similar. (This is, of course, assuming reliable scheduling based on wall clock time is actually achievable)

My suggestion was more about every being able to operate on elapsed time rather than a fixed tick count, either through a separate syntax or implementation.

Regarding feasibility, wouldn't it be possible to calculate the next tick delay using the server's configured tick rate? For example, on a 30 TPS server, every 1 second could schedule for 30 ticks, while on a 20 TPS server it would schedule for 20 ticks. The underlying scheduling would still be done through Bukkit's tick scheduler; the difference would just be how the delay is calculated.

[sovdeeth]

This would be a massive breaking change and a significant change to how Skript schedules tasks, if it is even feasible. Scheduling still has to use the Bukkit scheduler at some point, and that works on a tick-based delay, not a real-time delay. This would also require us to differentiate between tick timespans and non-tick timespans, which would be another significant breaking change and complicate code paths.
I am strongly against this change.
If a 'wall clock' delay capability is required, I would rather it look more like wait 1 seconds in real time or similar. (This is, of course, assuming reliable scheduling based on wall clock time is actually achievable)

My suggestion was more about every being able to operate on elapsed time rather than a fixed tick count, either through a separate syntax or implementation.

Regarding feasibility, wouldn't it be possible to calculate the next tick delay using the server's configured tick rate? For example, on a 30 TPS server, every 1 second could schedule for 30 ticks, while on a 20 TPS server it would schedule for 20 ticks. The underlying scheduling would still be done through Bukkit's tick scheduler; the difference would just be how the delay is calculated.

No, because the tick rate could change at any moment, especially if the server encounters lag. A 10 second delay could calculate 200 ticks of delay, but by a 2 second lag spike in there, or a short tick sprint (for whatever reason the user chose) means it could be off by multiple seconds in either direction.

[bluelhf]

We could implement a stable-ish wall clock periodical by using a wall clock timer that triggers an event to run on the next server tick, or equivalently with a tick task that runs the triggers of registered wall clock periodicals for which the next event is scheduled to run before the next server tick. Care should be taken if we implement fixed-rate periodicals, since something like

every tick of fixed-rate wall clock time:
  # do something that takes more than 1 tick on average

would crash the server

[sovdeeth]

We could implement a stable-ish wall clock periodical by using a wall clock timer that triggers an event to run on the next server tick, or equivalently with a tick task that runs the triggers of registered wall clock periodicals for which the next event is scheduled to run before the next server tick. Care should be taken if we implement fixed-rate periodicals, since something like

every tick of fixed-rate wall clock time:

do something that takes more than 1 tick on average

would crash the server

yeah this would be the most feasible, but it still falls prey to fluctuating tick times if the current tick before the scheduled one takes an abnormally long time. It's how I would implement it, but even then if you encounter an abnormal delay for a tick, you could get your wall clock time thrown off by a non-negligible amount (like mentioned with the crash situation, but with unrelated work that takes more than a tick)