Bug: Safe listener lambdas are scheduled instead of executing immediately

[emyfops]

What happened?

Some people have come across this issue where the velocity module would not cancel velocity update packets. There was a patch in #181 but it was merged before I could actually look into what was happening. In #100 the listeners were modified to be executed on the main thread, but this causes events from different threads to be scheduled for the next tick, which is bad because ideally listeners should never schedule for you, all the control should be given to the programmer

What should have happened?

x

Version

0.0.1

Log Output

No response

[emyfops]

@Avanatiker need your feedback on this

[emyfops]

Here we can see that the thread posting the event is not the render thread, causing the lambda to be scheduled at TickEvent.Pre and messing the expected timing

[crosby-moe]

ideally it should be up to the developer, but touching render thread state unsafely from an event running offthread is an easy mistake to make

at the very least it shouldn't use runGameScheduled if the event is a CallbackEvent

[emyfops]

ideally it should be up to the developer, but touching render thread state unsafely from an event running offthread is an easy mistake to make

at the very least it shouldn't use runGameScheduled if the event is a CallbackEvent

You should only touch opengl on the correct events

[crosby-moe]

You should only touch opengl on the correct events

'render thread' as in the main one, not gl calls specifically