If you mean with normal period the plugin-scheduled time; The reason why I made the patch IS because they were scheduled close to each other like 1 minute apart from each other or so.
The running event manually / out of the scheduled time was just to show what happens and to reproduce the bug easielly.
Also, you can't schedule around it, even if you schedule them to be in the time intervals of 2 prime numbers, x and y, it would still overlap at the (x*y)th time. And I think thats the best you can mathematically do / achive. (Even with random, there is the theorem: https://en.wikipedia.org/wiki/Infinite_monkey_theorem ). It is mathematically unavoidable that the events cut each other of at some point in time.
And I think they are working OK enough outside their event dates, IF they are not scheduled on top of each other.
Ofcourse the bug is in Rust's event code, or at least it should be fixed there, but the bug never would occur in the real world since it is never halloween and easter at the same time. But this plugin can make that happen and I think that is a good thing, it's just that I can't think of any other place to prevent this bug from occuring other than this plugin.
As I stated before an adjustment of the scheduling process would be better and more clean, and my fix wasn't that clever in hindsight. So I will try to adjust the plugin so that everyone can be happy, hopefully. Give me a few days.
Merged postAlso, if it is the operators responsibility, why do something like this:
if (config.MinimumTimeBetween <= config.MaximumTimeBetween)
randomTime = Oxide.Core.Random.Range(config.MinimumTimeBetween, config.MaximumTimeBetween);
else
randomTime = Oxide.Core.Random.Range(config.MaximumTimeBetween, config.MinimumTimeBetween);