3775d21f76
* Networking api v1 Some final docs? Licenses and testmod Fix a bunch o imports and make things work for v1 (v0 is bork) Make the testmod pass checkstyle and work Docs for v1 * Deprecate v0 and implement using v1 * Drop files down one package due to package check error * Fix issue with channel registration, add another testmod * jaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaavadoc * Make javadoc use `code`, move impl interface to package access * this things * Rename a few internal methods * Mark all client side stuff client only, move client mixins * Add null checks around the place, clarify some javadoc and method names * Make FutureListeners uninstantiable * Some internal nullable annotations * An impl class I forgot to rename * Some comments and clarify some client login handler javadoc * Add a missing FunctionalInterface annotation * Split play and login, move client stuff to right package * No interface left behind * Inline channel registries in api * Login and play subpackages not needed * Add helper method to create play custom packets * hasGlobalChannel -> hasGlobalReceiver * Just rename the collection method for now * Inline PlayPacketSender into static methods * Start on testmod idea for verifying dynamic registration * Add client login events * You don't say hello when talking to yourself. Also more testmod stuff * Make event names present tense * Some javadoc and impl interface rename * Change the test keybinding * Begin working on dynamic reg * Dynamic reg works, just need a lot of cleanup and reimpling global * A few renames, readd global methods * Try to reduce the amount of duplicate registration logic * Reimplement dynamic accessors * More impl * Start reimplementing global receivers. Still very hacky solution. * Reimplement some server global reciever stuff * Add login init event for server login. * Implement client login query start event * Move event invocations into addon, don't dual register global recievers * Finally reimplement global recievers for all networking phases * A revelation: Send packets properly This also finds the issue with screen getting the proper S2C channels, current on TODO list. * Disconnect event does not need a packet sender * Clarify, add methods to get channels net handler can recieve on client * Unregister actually works now * Bunch of null checks, add simpler login delay test for vanilla clients * Add some debug logging entries, fix unregister on client's session reg * Play channel event javadoc and rename login query handlers * More channel -> channelName * thisening * Introduce the basics infrastructure for tracking global receivers * Add more substantial javadoc to login connection events * Javadoc, reimplement unreg methods on v0, 1 impl fix * Implement tracking for global recievers * Dont forget to start tracked sessions in 3/4 cases * Global receiver docs and move methods in classes * Complete null checks * big boi javadoc part 1 * Finish the main javadoc, usage javadoc is left * Set so has method is not needed * Rename receiveable and sendable methods * Add the two missing private ctors * buildscript update to upstream * Split out player finding stuff to networking player tracking API v1 Signed-off-by: liach <liach@users.noreply.github.com> Forward v0 PlayerStream to new module, add entity track events Rename module to player tracking Well javadoc can make sense Decide on tracking for the name Update fabric-player-tracking-api-v1/src/main/java/net/fabricmc/fabric/api/networking/player/tracking/v1/package-info.java Co-authored-by: Erlend Åmdal <erlend@aamdal.com> Remove exceptions from javadoc that are not thrown javadoc fix again Handle a case where the player manager happens to be null rename player tracking to player lookup Yeet * Cherrypick #1092 * Remove some redundant client networking methods, rename `(un)register` to `(un)registerReceiver` * Simplify access to dynamic reg on client * Param shifting, let users get sender. * Warning about time and distance units * Make sure these are client only * Fix control flow in ClientPlayNetworking#send * Correct example code javadoc * javadoc correction in server login * Put login delay tests behind system property Also remove unnecessary junk added by old module that was merged together. * Fix ordering so channel registrations during `PHASE`_INIT work * Fix prod bug and an oversight * Fix login when connecting to dedicated server * Update registry sync to v0 to prevent issue with reg sync hanging client * this is done |
||
---|---|---|
.github/workflows | ||
fabric-api-base | ||
fabric-biome-api-v1 | ||
fabric-blockrenderlayer-v1 | ||
fabric-command-api-v1 | ||
fabric-commands-v0 | ||
fabric-containers-v0 | ||
fabric-content-registries-v0 | ||
fabric-crash-report-info-v1 | ||
fabric-dimensions-v1 | ||
fabric-events-interaction-v0 | ||
fabric-events-lifecycle-v0 | ||
fabric-game-rule-api-v1 | ||
fabric-item-api-v1 | ||
fabric-item-groups-v0 | ||
fabric-key-binding-api-v1 | ||
fabric-keybindings-v0 | ||
fabric-lifecycle-events-v1 | ||
fabric-loot-tables-v1 | ||
fabric-mining-levels-v0 | ||
fabric-models-v0 | ||
fabric-networking-api-v1 | ||
fabric-networking-blockentity-v0 | ||
fabric-networking-v0 | ||
fabric-object-builder-api-v1 | ||
fabric-object-builders-v0 | ||
fabric-particles-v1 | ||
fabric-registry-sync-v0 | ||
fabric-renderer-api-v1 | ||
fabric-renderer-indigo | ||
fabric-renderer-registries-v1 | ||
fabric-rendering-data-attachment-v1 | ||
fabric-rendering-fluids-v1 | ||
fabric-rendering-v0 | ||
fabric-rendering-v1 | ||
fabric-resource-loader-v0 | ||
fabric-screen-handler-api-v1 | ||
fabric-structure-api-v1 | ||
fabric-tag-extensions-v0 | ||
fabric-textures-v0 | ||
fabric-tool-attribute-api-v1 | ||
gradle/wrapper | ||
src/main/resources | ||
.editorconfig | ||
.gitignore | ||
build.gradle | ||
checkstyle.xml | ||
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 install fabric loader first. More information about installing Fabric Loader can be found here.
To use Fabric API, download it from CurseForge or GitHub Releases.
The downloaded jar file should be placed in your mods
folder.
Using Fabric API to develop mods
To setup 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:
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-v0"
]
// Add each module as a dependency
apiModules.forEach {
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-v0"
).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.
Check out the Contributing guidelines*.
* The contributing guidelines are work in progress
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