Component API Implementation #146
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
components to saves.
Leo40Git
reviewed
Jul 15, 2022
library/core/qsl_base/src/main/java/org/quiltmc/qsl/base/api/util/Maybe.java
Outdated
Show resolved
Hide resolved
* Implemented initial sync. * Implemented sync requests. This is the last feature commit. From now on only improvements, until the initial release.
|
Consider the initial feature-set done! Feel free to start breaking this! |
library/data/component/src/main/resources/quilt_component.mixins.json
Outdated
Show resolved
Hide resolved
| * needs to implement this interface.<br/> | ||
| * | ||
| * <p> | ||
| * Currectly it consists of the {@link ComponentProvider#getComponentContainer()} method, which is the abstract one, |
There was a problem hiding this comment.
Currently, instead of Currectly
| * @see ComponentContainer | ||
| * @see Components | ||
| */ | ||
| @InjectedInterface({ // We inject this inteface, so that modders don't need to use the methods in Components directly with our default implementations. |
There was a problem hiding this comment.
interface instead of inteface
| public interface ComponentProvider { | ||
| /** | ||
| * Every {@linkplain ComponentProvider provider} must provide a {@link ComponentContainer}, | ||
| * so that it can store the components targetting or that are manually added to it. |
There was a problem hiding this comment.
targeting instead of targetting
lukebemish
reviewed
Aug 3, 2022
...y/data/component/src/main/java/org/quiltmc/qsl/component/api/provider/ComponentProvider.java
Outdated
Show resolved
Hide resolved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After 2 weeks of unhealthy head-banging I have finally finished this!
This API adds:
A bit of an explanation:
This module allows you attach data, functions, ticking functions to game objects.
Right now the following objects are implemented:
ItemStacks(Removed from the Initial Release)The data can be serialized using NBT and can also be network synced(although that feature is a bit unstable at the moment).
Component Injection
During the mod loading stage, mods are able to inject into difference game objects, provided those objects implement the ComponentProvider interface. Those injections are cached using the target class/classes and are then able to be quickly looked up.
But what about the case where cached injections don't suffice? one may ask.
Well that's also covered using dynamic injection.
Along with the class that you are targeting, you can also provide a predicate that will match the type of the class.
That predicate is then used when a provider is initialized to make sure it matches and/or can be injected into the target.
Proceed with caution: The predicate is checked, at the end of the constructor of the highest class in the hierarchy. This means that only the properties initialized up to that point will be available for querying!.
While that may not seem like a problem for things like ItemStacks, which generally aren't extended, Entities for example have a wide variety of classes with different fields. However, when injecting dynamically, one will only have access to the Entity class fields as well as the type information of the object.
Custom implementations
I have made the API really flexible, so that anyone can just create custom implementations of most provided objects.
Component containers, component providers, components, sync headers, all of those can be extended and tweaked as per need.
Network sync and data saving
Data is currently saved using NBT and a save call that is provided from the provider to its container.
Data is currently synced using a system I have implemented. Needless to say, this system needs some tweaking as well as a lot of testing to make sure that:
There are no runtime crashes caused by the system.Components are properly synced even in edge cases.Components are synced when the object is first loaded.I think that after all that is done, this will be able to be released.
Finally
Feel free to ask any questions about the implementation and provide feedback wherever possible.
This project was a massive undertaking for one person and that is why I decided to PR it now that it's reaching its final stages.
The codebase is big and documentation is needed, I understand that. However I still think I needed to share it with everyone.
Thank you for your time!