9ff28f4026
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. |
||
|---|---|---|
| .. | ||
| src | ||
| build.gradle | ||
| README.md | ||
Fabric API Lookup API (v1)
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. See also the package-info.java file.
- What we call an API is any object that can be offered or queried, possibly by different mods, to be used in an agreed-upon manner.
- This module allows flexible retrieving of such APIs, represented by the generic type
A, from blocks in the world or from item stacks. - It also provides building blocks for defining custom ways of retrieving APIs from other game objects.
Retrieving APIs from blocks
See the javadoc of BlockApiLookup for a full usage example.
BlockApiLookup
The primary way of querying API instances for blocks in the world.
It exposes a find function to retrieve an API instance, and multiple register* functions to register APIs for blocks and block entities.
Instances can be obtained using the get function.
BlockApiCache
A BlockApiLookup bound to a position and a server world, allowing much faster repeated API queries.
Retrieving APIs from items
See the javadoc of ItemApiLookup for a full usage example.
ItemApiLookup
The way to query API instances from item stacks.
It exposes a find function to retrieve an API instance, and multiple register* functions to register APIs for items.
Retrieving APIs from entities
See the javadoc of EntityApiLookup for a full usage example.
EntityApiLookup
The way to query API instances from entities.
Exposes a find function to retrieve an API instance, and multiple register* functions to register APIs for entity types.
Retrieving APIs from custom objects
The subpackage custom provides helper classes to accelerate implementations of ApiLookups for custom objects,
similar to the existing BlockApiLookup, but with different query parameters.
ApiLookupMap
A map meant to be used as the backing storage for custom ApiLookup instances, to implement a custom equivalent of BlockApiLookup#get.
ApiProviderMap
A fast thread-safe copy-on-write map meant to be used as the backing storage for registered providers.