ca8aad0623
Completes the data attachment API with client-server syncing capabilities. ## Motivation The existing API works great for attaching data to game objects, be they serverside or clientside, but lacks any ability to synchronize between the two. A mod that wants to add a "thirst" mechanic can easily do so on the server side by attaching an integer to every player. However, the mod may also want to use this information to render additional HUD elements on the client. Currently, informing the client of this data can only be done manually, which is cumbersome, error-prone, and is much better-suited as an API feature. ## API Changes The API doesn't change a lot (at least compared to the implementation), with a few new methods and one new class. One new method has been added to `AttachmentRegistry.Builder`, namely `syncWith`. It declares that an attachment type may be synchronized with some clients, and takes a `PacketCodec` to encode attachment data over the network, as well as an element of the new `AttachmentSyncPredicate` interface. This interface extends `BiPredicate<AttachmentTarget, ServerPlayerEntity>` to allow for user-defined predicates, and provides some common presets: * `all()`: attachment data will be synchronized with all clients (that track the target). * `targetOnly()`: attachment data will only be synchronized with the target it is attached to, when it is a player. If the target is not a player, it won't be synchronized with any client. * `allButTarget()`: reverse of the above. For non-player targets, attachment data will be synchronized with all clients. **NOTE**: for a user-defined condition, whether attachment data is synchronized with a client can change at runtime (e.g. "sync only with operators" when a player changes operator status). A specialized method to "refresh" data was considered, but in the end discarded due to complexity. It falls to individual mods to handle these edge cases. AttachmentType also gets one new `isSynced` method to know whether a given attachment type can be synced. ## Usage Here is how one could register an attachment for a "thirst" meter like mentioned above. ```java public static final AttachmentType<Integer> THIRST = AttachmentRegistry.<Integer>builder() .initializer(() -> 20) // start with a default value like hunger .persistent(Codec.INT) // persist across restarts .syncWith(PacketCodecs.VAR_INT.cast(), AttachmentSyncPredicate.targetOnly()) // only the player's own client needs the value for rendering .buildAndRegister(Identifier.of("modid", "thirst")); ``` |
||
---|---|---|
.github | ||
deprecated | ||
fabric-api-base | ||
fabric-api-bom | ||
fabric-api-catalog | ||
fabric-api-lookup-api-v1 | ||
fabric-biome-api-v1 | ||
fabric-block-api-v1 | ||
fabric-block-view-api-v2 | ||
fabric-blockrenderlayer-v1 | ||
fabric-client-tags-api-v1 | ||
fabric-command-api-v2 | ||
fabric-content-registries-v0 | ||
fabric-convention-tags-v2 | ||
fabric-crash-report-info-v1 | ||
fabric-data-attachment-api-v1 | ||
fabric-data-generation-api-v1 | ||
fabric-dimensions-v1 | ||
fabric-entity-events-v1 | ||
fabric-events-interaction-v0 | ||
fabric-game-rule-api-v1 | ||
fabric-gametest-api-v1 | ||
fabric-item-api-v1 | ||
fabric-item-group-api-v1 | ||
fabric-key-binding-api-v1 | ||
fabric-lifecycle-events-v1 | ||
fabric-loot-api-v3 | ||
fabric-message-api-v1 | ||
fabric-model-loading-api-v1 | ||
fabric-networking-api-v1 | ||
fabric-object-builder-api-v1 | ||
fabric-particles-v1 | ||
fabric-recipe-api-v1 | ||
fabric-registry-sync-v0 | ||
fabric-renderer-api-v1 | ||
fabric-renderer-indigo | ||
fabric-rendering-fluids-v1 | ||
fabric-rendering-v1 | ||
fabric-resource-conditions-api-v1 | ||
fabric-resource-loader-v0 | ||
fabric-screen-api-v1 | ||
fabric-screen-handler-api-v1 | ||
fabric-sound-api-v1 | ||
fabric-transfer-api-v1 | ||
fabric-transitive-access-wideners-v1 | ||
gradle | ||
src | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
build.gradle | ||
checkstyle.xml | ||
CONTRIBUTING.md | ||
crowdin.yml | ||
gradle.properties | ||
gradlew | ||
gradlew.bat | ||
HEADER | ||
LICENSE | ||
README.md | ||
settings.gradle |
Fabric API
Essential hooks for modding with Fabric.
Fabric API is the library for essential hooks and interoperability mechanisms for Fabric mods. Examples include:
- Exposing functionality that is useful but difficult to access for many mods such as particles, biomes and dimensions
- Adding events, hooks and APIs to improve interopability between mods.
- Essential features such as registry synchronization and adding information to crash reports.
- An advanced rendering API designed for compatibility with optimization mods and graphics overhaul mods.
Also check out Fabric Loader, the (mostly) version-independent mod loader that powers Fabric. Fabric API is a mod like any other Fabric mod which requires Fabric Loader to be installed.
For support and discussion for both developers and users, visit the Fabric Discord server.
Using Fabric API to play with mods
Make sure you have installed fabric loader first. More information about installing Fabric Loader can be found here.
To use Fabric API, download it from CurseForge, GitHub Releases or Modrinth.
The downloaded jar file should be placed in your mods
folder.
Using Fabric API to develop mods
To set up a Fabric development environment, check out the Fabric example mod and follow the instructions there. The example mod already depends on Fabric API.
To include the full Fabric API with all modules in the development environment, add the following to your dependencies
block in the gradle buildscript:
Groovy DSL
modImplementation "net.fabricmc.fabric-api:fabric-api:FABRIC_API_VERSION"
Kotlin DSL
modImplementation("net.fabricmc.fabric-api:fabric-api:FABRIC_API_VERSION")
Alternatively, modules from Fabric API can be specified individually as shown below (including module jar to your mod jar):
Groovy DSL
// Make a collection of all api modules we wish to use
Set<String> apiModules = [
"fabric-api-base",
"fabric-command-api-v1",
"fabric-lifecycle-events-v1",
"fabric-networking-api-v1"
]
// Add each module as a dependency
apiModules.forEach {
include(modImplementation(fabricApi.module(it, FABRIC_API_VERSION)))
}
Kotlin DSL
// Make a set of all api modules we wish to use
setOf(
"fabric-api-base",
"fabric-command-api-v1",
"fabric-lifecycle-events-v1",
"fabric-networking-api-v1"
).forEach {
// Add each module as a dependency
modImplementation(fabricApi.module(it, FABRIC_API_VERSION))
}
Instead of hardcoding version constants all over the build script, Gradle properties may be used to replace these constants. Properties are defined in the gradle.properties
file at the root of a project. More information is available here.
Contributing
See something Fabric API doesn't support, a bug or something that may be useful? We welcome contributions to improve Fabric API. Make sure to read the development guidelines.
Modules
Fabric API is designed to be modular for ease of updating. This also has the advantage of splitting up the codebase into smaller chunks.
Each module contains its own README.md
* explaining the module's purpose and additional info on using the module.
* The README for each module is being worked on; not every module has a README at the moment