So I’ve been looking through the API to see if I can get a way to get the server’s update time. All I can find is Server.getTicksPerSecond()
I see there’s an array ,@Shadow @Final public long tickTimeArray; , that can be averaged out to get a tps, but through the API there seems to be no way to access that already existing information. Is there a good way to get the update time through the API or any recommendations as to how I can calculate out an Update time.
The only other way that I see (in my sleep addled mind), is to make a mixin to override it and make it public (or maybe use Java Reflection if you are feeling really brave, although I cannot endorse doing this).
If you don’t mind me asking, why is it vital that you know the timing of each tick?
First off, I’d like to apologize if I came off as rude in my last statement. I’m also on the edge of passing out haha. So I get what you mean no worries.
Well that average is important. People catch problems when the TPS goes below 20… But the tps is capped at 20, it’s just a “nice” number to look at. Watching performance on a server with 10 people with a constant 14ms update time, everything’s fine, everyone’s happy, someone places something obscure or makes some weird contraption with some badly coded item. suddenly that update time goes up to 48ms. TPS still show’s 20…but there’s obviously a performance problem that needs to be addressed, but my current monitoring tools only send TPS, and so I won’t be alerted till the next person joins and suddenly everyone’s lagging because it threw it over the edge…I’m just trying to get the update time efficiently. The performance was a “problem” before the TPS ever hit 19.99, but since it’s capped at 20, if I solely use the TPS to monitor, I can’t catch problems before they start actually affecting the player’s experience.
The Update time is a much more accurate number, representative of performance rather than an average over that time on a capped number. Generally it’s nice to see oh I’m getting less than 20 ticks every second, maybe I should change something. But for me it’s more of That’s how long It’s taking to complete the calculations, I can divide by the 50 whenever, nbd.
I tried doing that but It won’t recognize it in my IDE. I’m working with SpongeForge. Actually, what dependency is that from? Seems like mix-in territory. Ohhh I just saw what you mean…yeahh…Well It would be nice to be able to get that information from the API either way.
*PS I’ve made comments about a TPS just being “nice” to look it, but I do understand the point of the cap. The cap isn’t at 20 TPS though… it would be at 50 ms, and the TPS a cleaner representation of that. It’s also a number that decreases as it gets worse, so it’s conceptually easier to understand in that fashion. Same goes for FPS. just saying I don’t want any angry rants about not understanding the point of the representation of the Update time in TPS, I just want an update time in ms.
Come to think of it, the other thing you might be able to do is listen for the tick event and get the current time milliseconds in that and update a counter or something. (Although this feels like a bad idea…)
20TPS is 50ms so unless a tick goes above that it shouldn’t be considered an issue (at least with TPS).
The reason why getTicksPerSecond() is capped at 20 is because the server will sleep until a total of 50ms has passed.
(literally just Thread.sleep(Math.max(1L, 50L - i)); where i is the time taken to tick)
Therefore any performance issue up to 50ms shouldn’t be noticeable gameplay wise. Of course at an Operating System level, during the sleep other processes may be scheduled to do something useful, whereas a maxed-out server will have to interrupt the game to schedule other tasks.
If you want the raw tick values then you’ll have to go into the game internals (either as a forge mod or just using MCP), and use tickTimeArray as @d4rkfly3r suggested.
Use ((MinecraftServer) Sponge.getServer()).tickTimeArray if you don’t want to depend on forge.
I’d like to point out that you missed the whole part where I explained that problems exists even when they’re not noticeable. And yes I’ll just be using the game internals. But if the API exposes the tps it should also expose the update time I think. In my experience, and with my values I believe problems should be fixed before they’re noticeable to the public. That’s just how I like to do things.