e747827905
* Improve loot table API Alternative to #629. - Deprecates all classes and methods that use outdated Yarn names. - Adds FabricLootTable and FabricLootTableBuilder to replace the LootSupplier naming variants. - Deprecates LootEntryTypeRegistry and LootJsonParser as their functionality is exposed in vanilla now. - Adds methods to FabricLootPoolBuilder for working with collections as builder parameters. - FabricLootPool and FabricLootTable/Supplier now return immutable lists instead of modifiable fixed-size ones. Still WIP: LootTableLoadingCallback uses the deprecated FabricLootSupplier. Update fabric-loot-tables-v1/src/main/java/net/fabricmc/fabric/api/loot/v1/FabricLootTableBuilder.java Co-authored-by: i509VCB <i509vcb@gmail.com> Fix compilation Create loot table API v2 Move incorrect classes and revert unnecessary change Add test for replacing loot tables Document FabricLootPools builder() -> create() Add accessor for LootPool.bonusRolls Add loot pool builder method for bonus rolls Use Blocks.DIRT.getLootTableId() instead of raw string in v1 loot test mod Make links in deprecation docs cleaner Make FabricLootPoolBuilder.copyFrom(pool, true) also copy bonus rolls ...and mention it in the javadoc Remove copyFrom from v2 builders It seems like a maintainability mess if Mojang ever decides to extend loot tables, and the chosen boolean flags are arbitrary. It also doesn't really have use cases apart from the internal use in the copyOf methods, and even then users can replicate its functionality with the other API methods. Rename 'supplier' to 'table' in LootManagerMixin Add 'stable' lifecycle to loot-table-api-v2, deprecate v1 Add internal comment for implementors about updates Cancel all remaining callbacks when a loot table is replaced Remove unused shadowed logger from LootManagerMixin Migrate subproject versioning to new system Start the AW migration Update test mod * Use interface injection * Fix some issues * Remove outdated bonusRolls test from LootTest It's a vanilla feature now. * Create transitive access widener module * Replace LootTableLoadingCallback with two events * Use friendlier exception message * Add resource source tracking * Add loot table sources * Add resource pack source for DefaultResourcePack$1 (anon resource) * Add license header * Make FabricResource an internal API in resource loader * Remove my TAW module * Add loot table-related TAWs * Run CI * Fix LootUtil.determineSource giving null values * Clarify LootUtil comment * Rename loot-table-api => loot-api + minor comment changes * Add README * Fix mixin file name * Use ImmutableMap.Builder instead of HashMap.computeIfAbsent in loot event impl * Prefix accessor methods with fabric_ to prevent conflicts with loot v1 * Document mixins * Document mixins more extensively * Improve NRMMixin comments * Change weird wording in FabricResourceImpl * Minor updates - Support new built-in mod respack source - Fix ResourceMixin comment - Add more docs to LootTableEvents.MODIFY - Add package-info * Add license header |
||
---|---|---|
.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-convention-tags-v1 | ||
fabric-crash-report-info-v1 | ||
fabric-data-generation-api-v1 | ||
fabric-dimensions-v1 | ||
fabric-entity-events-v1 | ||
fabric-events-interaction-v0 | ||
fabric-events-lifecycle-v0 | ||
fabric-game-rule-api-v1 | ||
fabric-gametest-api-v1 | ||
fabric-item-api-v1 | ||
fabric-item-groups-v0 | ||
fabric-key-binding-api-v1 | ||
fabric-keybindings-v0 | ||
fabric-lifecycle-events-v1 | ||
fabric-loot-api-v2 | ||
fabric-loot-tables-v1 | ||
fabric-mining-level-api-v1 | ||
fabric-models-v0 | ||
fabric-networking-api-v1 | ||
fabric-networking-v0 | ||
fabric-object-builder-api-v1 | ||
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-conditions-api-v1 | ||
fabric-resource-loader-v0 | ||
fabric-screen-api-v1 | ||
fabric-screen-handler-api-v1 | ||
fabric-textures-v0 | ||
fabric-transfer-api-v1 | ||
fabric-transitive-access-wideners-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