2019-04-23 18:46:23 -04:00
|
|
|
pluginManagement {
|
|
|
|
|
repositories {
|
|
|
|
|
gradlePluginPortal()
|
|
|
|
|
maven {
|
|
|
|
|
name = 'Fabric'
|
|
|
|
|
url = 'https://maven.fabricmc.net/'
|
|
|
|
|
}
|
|
|
|
|
mavenLocal()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-24 13:15:08 -04:00
|
|
|
rootProject.name = "fabric-api"
|
|
|
|
|
|
2024-01-11 10:45:18 -05:00
|
|
|
include 'fabric-api-bom'
|
|
|
|
|
include 'fabric-api-catalog'
|
|
|
|
|
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-api-base'
|
|
|
|
|
|
2021-03-08 15:32:36 -05:00
|
|
|
include 'fabric-api-lookup-api-v1'
|
2022-02-21 06:58:35 -05:00
|
|
|
include 'fabric-biome-api-v1'
|
2022-11-07 13:29:51 -05:00
|
|
|
include 'fabric-block-api-v1'
|
2023-09-03 08:06:21 -04:00
|
|
|
include 'fabric-block-view-api-v2'
|
2019-09-20 19:50:49 -04:00
|
|
|
include 'fabric-blockrenderlayer-v1'
|
2023-09-03 08:06:21 -04:00
|
|
|
include 'fabric-client-tags-api-v1'
|
2022-05-20 13:39:10 -04:00
|
|
|
include 'fabric-command-api-v2'
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-content-registries-v0'
|
2024-04-16 13:01:57 -04:00
|
|
|
include 'fabric-convention-tags-v2'
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-crash-report-info-v1'
|
2024-01-19 06:14:33 -05:00
|
|
|
include 'fabric-data-attachment-api-v1'
|
2021-12-03 08:35:29 -05:00
|
|
|
include 'fabric-data-generation-api-v1'
|
2020-11-28 14:47:10 -05:00
|
|
|
include 'fabric-dimensions-v1'
|
2020-12-30 11:43:22 -05:00
|
|
|
include 'fabric-entity-events-v1'
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-events-interaction-v0'
|
2020-07-24 11:25:09 -04:00
|
|
|
include 'fabric-game-rule-api-v1'
|
2021-08-31 08:59:35 -04:00
|
|
|
include 'fabric-gametest-api-v1'
|
2020-06-25 17:28:21 -04:00
|
|
|
include 'fabric-item-api-v1'
|
2022-10-22 15:38:33 -04:00
|
|
|
include 'fabric-item-group-api-v1'
|
2020-06-12 06:18:17 -04:00
|
|
|
include 'fabric-key-binding-api-v1'
|
2020-06-25 17:28:21 -04:00
|
|
|
include 'fabric-lifecycle-events-v1'
|
2024-03-27 12:47:29 -04:00
|
|
|
include 'fabric-loot-api-v2'
|
2022-06-02 11:00:15 -04:00
|
|
|
include 'fabric-message-api-v1'
|
Model Loading API v1 (#3145)
This PR deprecates and supersedes the old `fabric-models-v0` module.
## Refactors compared to v0
### Model loading hooks
Mods now register a single `ModelLoadingPlugin` for any change they want to make to the model loading process. (Or multiple plugins if they want to). This replaces the old `ModelLoadingRegistry`.
Here is an example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// ResourceManager access is provided like in the v0 API, but in a central place, and can be used for shared processing in the plugin.
ResourceManager manager = pluginContext.resourceManager();
// Model resource providers still exist, but they are called model resolvers now
pluginContext.resolveModel().register(context -> {
// ...
});
});
```
#### `ModelVariantProvider` -> `BlockStateResolver`
`ModelVariantProvider` was heavily reworked, and is now replaced by the `BlockStateResolver`, with a much better defined contract.
#### `ModelResourceProvider` -> `ModelResolver`
The resource provider is mostly unchanged. The biggest difference is that it is now registered as an event listener. This allows mods to use event phases for ordering between conflicting ~~providers~~ resolvers.
#### Removed custom exception
Additionally, `ModelProviderException` could be thrown by a variant or resource provider in the v0 API. This was not explained in the documentation, and would according to the code stop further processing of the providers and log an error.
In the new API, any `Exception` is caught and logged. If that happens, the other resolvers are still processed. There is no custom `Exception` subclass anymore.
### Helper method to get a `BakedModel` by `Identifier` from the manager
The v0 had such a method in a helper class: `BakedModelManagerHelper#getBakedModel`. It is now interface-injected instead. See `FabricBakedModelManager`.
## New model wrapping hooks
New hooks are added for the various needs of mods that want to override or wrap specific models. Thanks to @embeddedt for contributing an initial version of them!
Here is an example of wrapping the gold model to remove the bottom quads, for example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// remove bottom face of gold blocks
pluginContext.modifyModelAfterBake().register(ModelModifier.WRAP_PHASE, (model, context) -> {
if (context.identifier().getPath().equals("block/gold_block")) {
return new DownQuadRemovingModel(model);
} else {
return model;
}
});
});
```
There are 3 events, for the following use cases:
- Wrapping `UnbakedModel`s right when they are loaded. This allows replacing them entirely in dependent models too.
- Wrapping `UnbakedModel`s right before they are baked. This allows replacing them without affecting dependent models (which might not be expecting a model class change).
- Wrapping `BakedModel`s right when they are baked.
Multiple mods have implemented their own version of them. Providing them in Fabric API will make it easier on these mods, and will additionally allow optimization mods that perform on-demand model loading to simply fire the hooks themselves instead of working around injections performed by other mods.
Co-authored-by: embeddedt <42941056+embeddedt@users.noreply.github.com>
Co-authored-by: PepperCode1 <44146161+PepperCode1@users.noreply.github.com>
Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com>
2023-07-18 07:53:13 -04:00
|
|
|
include 'fabric-model-loading-api-v1'
|
Fabric Networking API V1 (#1081)
* 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
2020-12-05 14:06:42 -05:00
|
|
|
include 'fabric-networking-api-v1'
|
2020-04-29 17:48:08 -04:00
|
|
|
include 'fabric-object-builder-api-v1'
|
2024-04-14 08:26:09 -04:00
|
|
|
include 'fabric-particles-v1'
|
2023-01-05 07:49:19 -05:00
|
|
|
include 'fabric-recipe-api-v1'
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-registry-sync-v0'
|
2019-05-18 16:25:27 -04:00
|
|
|
include 'fabric-renderer-api-v1'
|
2019-09-18 18:24:15 -04:00
|
|
|
include 'fabric-renderer-indigo'
|
2019-05-17 17:24:37 -04:00
|
|
|
include 'fabric-rendering-fluids-v1'
|
2023-09-03 08:06:21 -04:00
|
|
|
include 'fabric-rendering-v1'
|
2022-01-14 10:08:18 -05:00
|
|
|
include 'fabric-resource-conditions-api-v1'
|
2019-05-11 17:48:33 -04:00
|
|
|
include 'fabric-resource-loader-v0'
|
2021-01-25 13:17:17 -05:00
|
|
|
include 'fabric-screen-api-v1'
|
2020-06-15 17:00:54 -04:00
|
|
|
include 'fabric-screen-handler-api-v1'
|
2022-10-16 10:09:44 -04:00
|
|
|
include 'fabric-sound-api-v1'
|
2024-03-01 12:46:49 -05:00
|
|
|
include 'fabric-transfer-api-v1'
|
2022-03-13 09:52:38 -04:00
|
|
|
include 'fabric-transitive-access-wideners-v1'
|
2022-05-01 10:44:16 -04:00
|
|
|
|
|
|
|
|
include 'deprecated'
|
2022-05-20 13:39:10 -04:00
|
|
|
include 'deprecated:fabric-command-api-v1'
|
2023-09-03 08:06:21 -04:00
|
|
|
include 'deprecated:fabric-commands-v0'
|
2024-04-16 13:01:57 -04:00
|
|
|
include 'deprecated:fabric-convention-tags-v1'
|
2022-05-01 10:44:16 -04:00
|
|
|
include 'deprecated:fabric-keybindings-v0'
|
Model Loading API v1 (#3145)
This PR deprecates and supersedes the old `fabric-models-v0` module.
## Refactors compared to v0
### Model loading hooks
Mods now register a single `ModelLoadingPlugin` for any change they want to make to the model loading process. (Or multiple plugins if they want to). This replaces the old `ModelLoadingRegistry`.
Here is an example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// ResourceManager access is provided like in the v0 API, but in a central place, and can be used for shared processing in the plugin.
ResourceManager manager = pluginContext.resourceManager();
// Model resource providers still exist, but they are called model resolvers now
pluginContext.resolveModel().register(context -> {
// ...
});
});
```
#### `ModelVariantProvider` -> `BlockStateResolver`
`ModelVariantProvider` was heavily reworked, and is now replaced by the `BlockStateResolver`, with a much better defined contract.
#### `ModelResourceProvider` -> `ModelResolver`
The resource provider is mostly unchanged. The biggest difference is that it is now registered as an event listener. This allows mods to use event phases for ordering between conflicting ~~providers~~ resolvers.
#### Removed custom exception
Additionally, `ModelProviderException` could be thrown by a variant or resource provider in the v0 API. This was not explained in the documentation, and would according to the code stop further processing of the providers and log an error.
In the new API, any `Exception` is caught and logged. If that happens, the other resolvers are still processed. There is no custom `Exception` subclass anymore.
### Helper method to get a `BakedModel` by `Identifier` from the manager
The v0 had such a method in a helper class: `BakedModelManagerHelper#getBakedModel`. It is now interface-injected instead. See `FabricBakedModelManager`.
## New model wrapping hooks
New hooks are added for the various needs of mods that want to override or wrap specific models. Thanks to @embeddedt for contributing an initial version of them!
Here is an example of wrapping the gold model to remove the bottom quads, for example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// remove bottom face of gold blocks
pluginContext.modifyModelAfterBake().register(ModelModifier.WRAP_PHASE, (model, context) -> {
if (context.identifier().getPath().equals("block/gold_block")) {
return new DownQuadRemovingModel(model);
} else {
return model;
}
});
});
```
There are 3 events, for the following use cases:
- Wrapping `UnbakedModel`s right when they are loaded. This allows replacing them entirely in dependent models too.
- Wrapping `UnbakedModel`s right before they are baked. This allows replacing them without affecting dependent models (which might not be expecting a model class change).
- Wrapping `BakedModel`s right when they are baked.
Multiple mods have implemented their own version of them. Providing them in Fabric API will make it easier on these mods, and will additionally allow optimization mods that perform on-demand model loading to simply fire the hooks themselves instead of working around injections performed by other mods.
Co-authored-by: embeddedt <42941056+embeddedt@users.noreply.github.com>
Co-authored-by: PepperCode1 <44146161+PepperCode1@users.noreply.github.com>
Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com>
2023-07-18 07:53:13 -04:00
|
|
|
include 'deprecated:fabric-models-v0'
|
2022-05-01 10:44:16 -04:00
|
|
|
include 'deprecated:fabric-renderer-registries-v1'
|
2023-09-03 08:06:21 -04:00
|
|
|
include 'deprecated:fabric-rendering-data-attachment-v1'
|
2022-05-01 10:44:16 -04:00
|
|
|
include 'deprecated:fabric-rendering-v0'
|
