I am aware that it's been 5 years, but I just ran into an issue where I would need this exact feature and figured I could expose how it can be useful primarily as a debug tool for developers.

Here is the scenario (not looking for a solution, just setting the scene):

I have a bit of code that I suspect is running twice per tick when it should be running once. This is a tricky bit of code, because it is a core element of the 50k line plugin I'm working on.

The plugin is large enough that outputting stack traces for edge conditions only isn't really giving me enough info to try to find a solution, and the code runs so frequently that stack tracing every code execution would be extremely hard to parse.

Already, being able to check which tick the code is running on would allow me to know if the issue is with the code running twice in a tick or with some other element of the plugin.

Further, because this is a critical part of my plugin, and it is important to me that it runs well, I have decided to add my own per-object log when in debug mode so that code execution can be easily traced back. On these logs I am putting both real time and the server tick it ran on so I can more easily understand if something is causing the same code to be executed several times within a tick, which would be the case if I messed up handling events or schedulers.

Please note that I am not saying that what I've listed isn't resolvable by other means, but this would be a great utility method for people looking to debug schedulers / events.

Please avoid repeatedly editing your comments, you just sent everyone watching this ticket another 12 emails.

>Should be getFullTime
getFullTime returns the world's 'day time' currently (might be a bug, or a World#getAge() would be a useful addition). And it is also modifiable by plugins, and gets modified currently even when only setting the 'daytime' via World#setTime().

>I'm arguing it shouldn't be exposed because with the exception of one or two things, a tick is an abstract concept. It has no physical, fixed, or defined analogue in most cases. You can't define API around something that changes or can be changed arbitrarily unless it is unavoidable, and it's not unavoidable in this case.

Well, then one could simply give it a 'plausible meaning', by naming it, analogue to minecraft's existing world time / age, 'Server#getTime()', returning the 'in-game time since server start' (representing some 'universe' time / age). And this time happens to be measured in ticks currently, with no guarantee that this won't be changed in the future, just like world time.
If viewing a tick as minecraft's in-game time unit, it is no longer abstract / it has a clearly defined meaning which plugins should be able to access.

>World 'age' is not accessible in the API as far as I can see currently. Only 'day time'.

Should be getFullTime

I'm arguing it shouldn't be exposed because with the exception of one or two things, a tick is an abstract concept. It has no physical, fixed, or defined analogue in most cases. You can't define API around something that changes or can be changed arbitrarily unless it is unavoidable, and it's not unavoidable in this case.

>World age is persistent and has actual meaning within the game.
World 'age' is not accessible in the API as far as I can see currently. Only 'day time'.

Anyways, it's bound to a world. If I would want to find out how much 'minecraft time' has passed (regardless of any world) I would always first need to query the current world age of 'some' world (and later be able to query the age again from the same world). Even though I am not really interested in any 'world-specific' data.

But the main point isn't so much about world time alone. It's just another example where minecraft counts ticks for tracking and comparing time, and that it would therefore make sense to expose the 'counted ticks since server start' to plugins as well.

>Another use is the time of worlds, which is measured in ticks as well. With this addition it would be possible to get the passed time in ticks independently of any world and any possible changes to its time. For example if a plugin needs to know how much 'minecraft time' has passed since some event X.

World age is persistent and has actual meaning within the game. Ticks since server start does not.

Well, like already said, ticks are used as measure of time in minecraft and the bukkit scheduler, and therefore in plugins, right now. Plugins are specifying delays in ticks, because ticks are the finest possible scale minecraft / the bukkit scheduler can use for delayed actions. And I doubt this will change anytime soon.

Another use is the time of worlds, which is measured in ticks as well. With this addition it would be possible to get the passed time in ticks independently of any world and any possible changes to its time. For example if a plugin needs to know how much 'minecraft time' has passed since some event X.

So as of right now I would find this (tiny) addition useful and a valid complement to the existing and currently used API.

>Regardless as to whether or not it's a good idea to use ticks in scheduling, it's already exposed.
Right - doesn't mean we need to expose if further with additions such as this.

Regardless as to whether or not it's a good idea to use ticks in scheduling, it's already exposed.

In any case, the idea of ticks is definitely needed in at least one other place - redstone. Or basically any other mechanic that is tied to redstone. While something that's user-facing or otherwise clientside should probably be wall-time, things that represent game state make sense off of ticks. If you wanted to make a plugin that acts as a variable redstone clock, then you need ticks. (Total ticks don't entirely come into play there as scheduling can be used, but such a plugin would probably have a situation where you'd need total ticks).

Exposing the concept of ticks even in the scheduler in the first place is a questionable design decision because just like in your example of a cooldown, it can be elongated unexpectedly and has absolutely no reference to what the end user experiences. If I say "this sword has a cooldown of 600 ticks" that could mean anywhere from 20 seconds to 120 seconds. A better approach would be to 1) Define your cooldowns in wall time (which can easily be updated through a task running every 20 ticks. Or 2) [hardmode] write a real time scheduling analogue for Bukkit. I am opposed to exposing the concept of ticks to the API any more than is necessary and I see this change as unnecessary with suitable alternatives already possible.

Well, this would be useful if one wants to use ticks as measure of time instead of wall time (if you mean 'actual' time by that).
If I expand on the 'lazy cooldown' example: Assume that the countdown isn't that 'lazy' anymore and I use a delayed task which triggers some action at cooldown end after a certain amount of ticks. So the cooldown is based on ticks and not wall time, because minecraft and the bukkit scheduler are based in ticks.
Now, if I want to also be able to find out how long the cooldown is already running or how much time is left, it would be preferably to get that time in ticks as well, and not wall time, because that would allow better comparison to the original duration of the cooldown (which was specified in ticks). Because the wall time could be completely different compared to the actual duration of the cooldown due to changes in the server's TPS.

As far as I can tell this is not possible without the plugin counting the ticks itself currently.

>Spontaneously I could think for example of 'lazy cooldowns' which are meant to last a certain amount of ticks

That's what wall time is for

I can see it being useful for situations where you want to have something last a certain amount of time, but want it to be tied to server time (ticks), and not real time (where lag could influence it). It's not something that would be needed in all situations, but I can see a number of places where it would be helpful.

Getting the current tick allows comparing tick counts at different times. Spontaneously I could think for example of 'lazy cooldowns' which are meant to last a certain amount of ticks and which can calculate the passed ticks and remaining ticks based on some 'start tick' and 'duration ticks' or 'end tick', without having to use a scheduler task to count down remaining ticks.

Why is this useful?