fabric/fabric-api-lookup-api-v1/build.gradle

version = getSubprojectVersion(project)

moduleDependencies(project, [
	'fabric-api-base',
	'fabric-lifecycle-events-v1'
])

testDependencies(project, [
	':fabric-rendering-v1',
	':fabric-object-builder-api-v1'
])
Update Loom and Loader. Cleanup/improve buildscript. 2021-11-12 07:48:58 -05:00			`version = getSubprojectVersion(project)`
Fabric API Lookup (#1234) # Fabric API Lookup API v1 ## Introduction This module allows Api instances to be associated with game objects without specifying how the association is implemented. This is useful when the same Api could be implemented more than once or implemented in different ways. Many thanks to @Grondag for providing the original concept (#1072). Thanks also go to @i509VCB, @Pyrofab, @sfPlayer1 and the others who were involved with the design of this module. This is the foundation upon which can be built for example a fluid transfer api (#1166). Closes #1199. ## Flexible Api Querying ## Block Api Usage example ## Building blocks This PR was changed a lot, please have a look at the README, the package info, and the javadoc for `BlockApiLookup` and `ApiLookupMap` for up-to-date documentation. ## More usage examples FastTransferLib (https://github.com/Technici4n/FastTransferLib) is an experiment to build an item, fluid and energy transfer api on top of this module. (Which was until recently called `fabric-provider-api-v1`.) ## Missing things? ~~I could add an overload of `BlockApiLookup#find` with nullable `BlockState` and `BlockEntity` parameters, so that the caller can directly provide them if they are available for some reason.~~ Added in later commits. There is no module to retrieve apis from items or entities yet because there were unsolved issues with those. The community can use the provided building blocks to experiment with their own implementations of `ItemStackApiLookup` and `EntityApiLookup` until the way forward becomes clear, but let's please not delay the `BlockApiLookup` because of that. Co-authored-by: i509VCB <git@i509.me> Co-authored-by: PepperBell <44146161+PepperCode1@users.noreply.github.com> (cherry picked from commit dc716ea1674642c756cb030eed411f0f4919e0e8) 2021-03-08 15:32:36 -05:00
			`moduleDependencies(project, [`
			`'fabric-api-base',`
			`'fabric-lifecycle-events-v1'`
			`])`

Split client only code into its own sourceset. (#2179) A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that. This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar. From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind. This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past. These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions. 2022-05-21 11:26:46 -04:00			`testDependencies(project, [`
			`':fabric-rendering-v1',`
			`':fabric-object-builder-api-v1'`
			`])`