I have not found an elegant solution for the following case yet:
A plugin's event handler is called by a world ticker thread A (which ticks world [1]) and accesses methods of another world [2], which modify the state of that world, while a world ticker thread B concurrently ticks world [2].
This may of course cause case conflicts and/or errors, as two or multiple thread are working on same set of data in such a case.
Just like it's a rule in the original CraftBukkit not to access the Bukkit API from outside the main thread, it is going to be a rule here, to avoid inter-world access within the event handlers. If the outcome of the event (cancelling it or not) is not depended on this inter-world access, then schedule a task which does that. In MinetickMod tasks are still only called by the main thread between world ticks (nothing changed there).
I have not found an elegant solution for the following case yet:
A plugin's event handler is called by a world ticker thread A (which ticks world [1]) and accesses methods of another world [2], which modify the state of that world, while a world ticker thread B concurrently ticks world [2].
This may of course cause case conflicts and/or errors, as two or multiple thread are working on same set of data in such a case.
Just like it's a rule in the original CraftBukkit not to access the Bukkit API from outside the main thread, it is going to be a rule here, to avoid inter-world access within the event handlers. If the outcome of the event (cancelling it or not) is not depended on this inter-world access, then schedule a task which does that. In MinetickMod tasks are still only called by the main thread between world ticks (nothing changed there).