Time Loop

[0xnim]

Is your feature request related to a problem?

Currently a tick loop exists, but its probably not the best to use it for time stuff. For example flushing something every 5 mins. A function of the server.

Describe the solution / feature you'd like.

I propose a time loop one that is standard, everything can use, internals and plugins alike. Preferably we can register a timer, and its run on an interval, so everything is not checking itself and counting every tick. Possibly with Bevy.

Alternatives you've considered.

Keep using TPS loop. I'm not quite familiar with bevys features, that might be the path on how to do this.

Additional Context

Bevy could possibly work. I have not looked into it yet.

I have confimed that...

• ... such a feature does not exist already.
• ... I ticked all the boxes without reading them
• ... such a feature request has not been submitted already.

[ReCore-sys]

I'll admit having a bunch of systems constantly check their own time isn't great, im not sure there's a better alternative. Bevy really only has schedules for doing this kinda thing, there's no built in timers or anything so we'd end up doing it with schedules anyway.

Since the current method has a bunch of systems that use a resource exclusive to them, it doesn't impact the parallelism much anyway cos bevy doesn't have to figure out how to run 2 systems using the same mutable resource so that isn't an issue.
Running everything on 1 schedule also lets us be specific about ordering if we need, ie we can specify that the world saving system needs to run after all the block update systems.
Another concern I have is that if we have a bunch of schedules all running at different speeds, we'd need to be constantly checking if any need to be run which would just lead to busy waiting, instead of the current system that just sleeps the app for 50ms (or whatever the tick rate is), then all the systems check if they could be run.

I'm aware of some issues with the current approach, mainly around the variable tick rate possibly leading to some systems being run much slower than intended, though this should be accounted for regardless as systems could be run slower due to heavy server load anyway.

I'm very open to solutions, I'm aware that the current system is flawed but I'm not sure if there's a better way. LMK if you got any ideas

[0xnim]

How about we have a time_loop, where we only look at the soonest due timer. And have functions to manage timers, register, etc. This way we have a single timer for all plugins and systems, and it wouldn't have any busy waiting except for the normal sleep.

[ReCore-sys]

That could work, but how would we actually run the schedule? The main thread is running at a predefined tick rate so we can't really hijack that and I don't think this warrants having yet another background thread

[0xnim]

We don't need to hijack anything or a new thread, we just slot it in as another ecs system.

[ReCore-sys]

but that means it'd have to run at the same rate as the rest of the server

[0xnim]

I suppose I was wrong then. But while it would run at server time, when it calls timer_tick. And be called whenever a tick runs, because of Instants, the time is still measured in real time. Then it would mean changing TPS only changes how often we poll the heap.

[ReCore-sys]

That's the issue, we can't guarantee that the tick rate is something sensible. Someone could set it to 1 tps and that'd likely break many timed systems that expect to be run faster, or they could set it to 500 tps and then polling would be a bottleneck at that point.

[ReCore-sys]

I suppose we could actually mess with the ticking loop, have a "main schedule" that isn't treated any differently from the other schedule, then instead of running 1 schedule in a loop we just constantly check which is the next schedule to run and sleep until it's time to run it.

[0xnim]

Well the reverse heap method checks only the latest. And would be o log n. So not too big of a problem, still an improvement from the current system o n on every timer. But the tps of 1 might. So then how do we consider the 2nd thread system?

[0xnim]

A thread blocking until the next timer is due could also work.

[0xnim]

@ReCore-sys So you think making a main loop, and possibly having a tps as any other timer? Just with a 50 ms interval?

That could very well work

[ReCore-sys]

kinda? my idea was to have the main thread just constantly work out which schedule is due to run next and sleep until it's time to run it, main game loop included. That way most schedules will run at roughly the frequency intended.
For example, imagine we have 3 schedules, A, B and C, that all run at different speeds. First we run A, then check to see which one comes next, which is B. So we sleep until B is ready and then run it. Then we check to see which comes next again, and see that A needs to go next, so we sleep until it's time to run it. Then we run it and check again, this time it's C, and we just repeat this loop forever.

[ReCore-sys]

This means that the tick rate of systems wouldn't impact the tick rate of other systems. You still wouldn't be able to guarantee a perfect tick rate since the server might be overloaded, but not much we can do about that.

[0xnim]

Yes, this is the implementation I had mocked up. We don't even need to check the other schedules, only the one that comes next, and sleep/block until it is due. Apologies if I had not clearly expressed that.