* Original fluid API design * Rework the transaction system * First javadoc pass * Add a testmod, a base implementation for fluid storages and fix some little bugs * Fix checkstyle * Make Movement#move extract from the view and not the whole Storage * Document and update FluidPreconditions * Use for-each in CombinedStorage and document a little * Remove useless overrides in Insertion/ExtractionOnlyStorage * Move SnapshotParticipant#snapshots to the top of the class, and make updateSnapshots public * Fix garbage collection of unused CauldronWrappers * Use ArrayList directly * Remove locking, reorganize transaction implementation, and add outer close callback * Add more javadoc * Rework Storage#forEach into Storage#iterator * Add a few missing `transaction.addCloseCallback(iterator)` * Add anyView(), exactView(), capacity() and isEmpty() * Add Storage#iterable to make iteration friendlier to for loops * Storages may now have multiple open iterators Co-authored-by: Devan-Kerman <dev.sel20@gmail.com> * Make CombinedStorage#supportsInsertion/Extraction iterate through the parts * Block updates should be used when the supportsInsertion/Extraction status changes * Fluid -> FluidKey * Remove all references to ItemKey inside FluidKey, and other minor tweaks * Cache FluidKeys with a null tag inside Fluid directly * Fluid unit convention * Add FluidKeyRendering and RenderHandler * Bump version for more testing (also published to my maven) * Add SingleViewIterator, massively reduce code duplication! * Make API experimental, and add README * Bump version * Apparently Fluids.EMPTY is flowing * Add package info * Minor adjustements * 1.17 port, cauldron support, add ResourceKey * Checkstyle, gas rendering, use record for ResourceAmount * Add a few helpers, rename some stuff * Remove anyView, allow nullable in StorageUtil#find*, fix missing try block * Slight findStoredResource cleanup * Slightly improve implementation * Bump version * Fix wrong transaction * I wrote in a comment that this could happen... * Fix SingleFluidStorage bugs, add tests in the testmod, add testmod assets * Add extract stick * Rename a few things * `ResourceKey<T>` -> `TransferKey<O>` * `ResourceKey#getResource()` -> `TransferKey#getObject()` as resource is already widely used through the API for the keys themselves. * `tag` -> `nbt` * Add `get` prefixes to `StorageView` functions * Bump version * FluidKey -> FluidVariant * Bump version * Expand getVersion() documentation, make it thread-safe and use long. Co-authored-by: Player <player@player.to> * empty resource -> blank resource, and update SingleFluidStorage Co-authored-by: Player <player@player.to> * Make CauldronFluidContent a final class instead of a record. Co-authored-by: Player <player@player.to> * Get rid of CauldronFluidContent#minLevel (was always 1) * Fix nested commits. (Thanks @warjort!) * Separate Transaction and TransactionContext Co-authored-by: Devan-Kerman <dev.sel20@gmail.com> Co-authored-by: Player <player@player.to> * Change WorldLocation into a private record * Bump version * Guard against exceptions thrown in close callbacks * Make sure blank fluid variants don't have a tag * Add documentation, make CauldronStorage clearer Co-authored-by: frqnny <45723631+frqnny@users.noreply.github.com> * Allow null storages in StorageUtil#move, and clarify sidedness of FluidStorage * Add explicit hashCode and equals for transfer variants * Remove ugly equals and hashCode overrides, and add constant time hashcode spec Co-authored-by: Devan-Kerman <dev.sel20@gmail.com> Co-authored-by: liach <liach@users.noreply.github.com> Co-authored-by: Player <player@player.to> Co-authored-by: frqnny <45723631+frqnny@users.noreply.github.com> |
||
---|---|---|
.github | ||
fabric-api-base | ||
fabric-api-lookup-api-v1 | ||
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-entity-events-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-api-v1 | ||
fabric-screen-handler-api-v1 | ||
fabric-structure-api-v1 | ||
fabric-tag-extensions-v0 | ||
fabric-textures-v0 | ||
fabric-tool-attribute-api-v1 | ||
fabric-transfer-api-v1 | ||
gradle | ||
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, GitHub Releases or Modrinth.
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 (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.
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