Links
Tags
Creators
Details
All versions
0.2.3-SNAPSHOT
Release
SignalsLib 0.2.3-SNAPSHOT5 days ago 12
Compatibility
Minecraft: Java Edition
26.3
26.2
26.1.x
1.21.x
1.20.x
1.19.x
1.18.x
1.17.x
1.16.x
Platform
Velocity
Changes
0.2.3-SNAPSHOT
Moves to GEB 0.5.4 and fixes the dispatcher registration it needs. No breaking changes to the signal API.
Fixed
SignalBusnow registers the dispatcher for its own events on the GEB bus it uses. It used to rely on GEB finding a generated dispatcher by itself, and GEB 0.5.4 does not: a newGEBregisters no dispatchers and drops events that have none without any warning, so no signal reached a listener.- The "GEB Direct Use" example in the README could not work on that GEB either, because nothing registered the dispatcher of the plugin's own listener. It now shows the registration step.
Added
GebBridge.registerDispatcher,unregisterDispatcherandloadAndRegisterDispatchers(ClassLoader). The last one reads the service file GEB's annotation processor writes into a plugin's jar, so a plugin with its own@Listenmethods registers its dispatchers with one call.- 6 new
signals-coretests (48 in total, was 42): aSignalBuson a plainGEB, sub-bus forwarding, events without a dispatcher being dropped (kept as a canary for GEB upgrades), registering and unregistering a dispatcher, loading dispatchers from a class loader's service file, and null checks.
Changed
- GEB core 0.5.0 is now 0.5.4, and the README points plugins at the annotation processor 0.4.9.
signals-coreno longer uses GEB's annotation processor.SignalEnvelopeDispatcheris written by hand, which is what the processor would have generated, andSignalBusregisters it. The module needs no annotation processing and does not depend on a service file being visible to a particular class loader.- Version is now
0.2.3-SNAPSHOT.
Supplementary resources
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:UxiIddjL:9vxL0Uph"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:UxiIddjL:9vxL0Uph"
}

