VRCTEvent v0.3.0

🔧 Changed

io.vrctools.common 0.2.1 or newer is now required
Handlers can no longer be unregistered while the emitter is invoking handlers (e.g. from within a handler function). Such calls are now rejected with an error, the same as registrations already were - see rules & gotchas
_CleanupHandlers() now does nothing and logs an error when called while the emitter is invoking handlers

🐞 Fixed

After a destroyed handler was removed, the remaining handlers for that event could be invoked with the wrong event name
Registering or unregistering a handler from within a handler function could cause other handlers to be skipped or invoked twice
A destroyed handler halted the emitter the next time the event was emitted, instead of being skipped with a warning
_UnregisterHandler(handler): removed handlers left empty entries behind, so the handler lists only ever grew
_UnregisterHandler(handler): calling it before any handler had been registered threw an exception
_UnregisterHandler(eventId, handler, eventName): the last handler registered for the event was also removed, unless the removed handler was the last one (fixed in io.vrctools.common 0.2.1)
Handler lists are no longer copied on every registration and unregistration when there is nothing to clean up

📚 Documentation

AbstractSynchronizedEventEmitter now explains that events are only delivered on the local client, and that subclasses must call the base implementation of every lifecycle method they override
The README examples now compile, use the correct names and check that the emitter still exists before unregistering in OnDestroy
The README now explains that handlers cannot be registered or unregistered while the emitter is invoking handlers
_UnregisterHandler(eventId, handler, eventName) and _EmitEvent now document their parameters