TickTimer

[xoft]

I think that "cap" is useless, I'll throw it out.

[bearbin]

Great

[xoft]

Done (rev 1353)

[FakeTruth]

What's gonna happen when the server is under heavy load now?
Instead of making the game run slower things will overshoot now, mobs will teleport around and pickups will fly everywhere.

[bearbin]

? Why would this happen. It's only a callback for plugins..

[xoft]

Nothing's gonna happen, since the physics still doesn't do anything based on the time.
On the other hand, we can finally detect overloads and react to them accordingly.

[FakeTruth]

Of course the physics use the delta time (its not the plugins I worry about).
You use the delta time to integrate velocity.
Things like this happen: position += velocity * deltatime
When deltatime is something really big for whatever reason the resulting position will be much further away then when using a small deltatime.

Look at this table, I believe it is called Euler integration?


Both have the same acceleration, but one has a timestep of one second and the other a timestep of 2 seconds

[bearbin]

Why don't you fix the problem there (in the velocity thingy) instead of doing a workaround in the tick that is shown to plugins - since the workaround is only applicable to one thing.

[xoft]

I think the physics should not use the deltatime. Actually, I think nothing should really use the deltatime. We measure time in ticks in the game, so let's measure it in ticks, really. If a tick takes longer, then whatever, the game will slow down a bit, who cares.

It's already a problem with furnaces, they don't cook the last item because of time rounding.

The server is running quite fine in recent versions, nothing makes the tick thread very overloaded, so ticks longer than 50 ms should be very rare anyway.

[bearbin]

Yeah, seems sensible. Although the server would slow down when the ticks slow, but the vanilla server does that anyway.