quilt-standard-libraries
quilt-standard-libraries copied to clipboard
Signal Channels
Provides an API for publishing and subscribing to events. Supports positional (origin+range, box), world, and global events, and positional, (block)entity-bound, and worldwide/global listeners.
Current implementation is a Proof-of-Concept and has no global listener support yet, as the listener subscriptions need to be heavily re-organized (either per-chunk storage or a data structure with quick access for neighboring coordinates).
The test mod has a regeneration block that emits events within 4 blocks of itself. Events are caught by player listeners and apply Regen I.
Im a bit confused/concerned about the passing of Codec<T>
everywhere, what problem is this trying to solve?
Named channels seems to already have an ID, so there must be some AoT communication about what data to expect, right?
Every instance of the named channel given by SignalChannel.getOrCreateNamed
gets its own codec but can share the ID with others. ID determines who gets it, and it's then re-encoded from the source codec to the target.
The intent of named channels is to be a way of communication between mods without a dependency. Some lightweight compat may not call for an optional dependency with all its pitfalls, so instead a named channel with the same ID as the other mod is created and subscribed to. The original type is not available, so a new one with a compatible Codec is created and used as the message type itself.
The conversion (kinda scuffed, it definitely should cache both codec steps) is in SubscriptionImpl.Named I believe.
How often is that codec based conversion likely to fire, in practice?
For each event fired, once for every unique subscribing codec, plus possibly an LRU cache on top for repeated identical events. So realistically once or twice per event at most? It's also not likely to be a big object to serialize to begin with.
Outside of better caching, the part I'm most unhappy about with this one is converting it through JSON, which is a lossy format.
Taking a bit of a deeper look, it doesnt seem like this currently support switching the bind at all? I can think of a few usages for that (i.e something that switches between block and entity form?) but you can cancel and and create a new subscription so I dont think its too major
As for the storage system, iirc minecraft itself already has something similar that could be reused? theres an EntityLookup<T extends EntityLike>
that might be possible to build around?