* Write to the trade map directly
* Add warning when TradeOfferHelper#refreshOffers is called
* Correctly use synchronized, just in case
* Add null check - PR should be ready for merge now
* Make ctor private to hide it from javadoc
* dynamic tool attributes v2, part 1
* move duck interface to impl package
* add licenses
* fix mixin build failure on a dedicated server
* remove unused shadow of getItem()
* add a simple user-context-based attribute tool to the test item suite
* add clarifying comments in DynamicAttributeTool jdoc regarding parameter reliability + extended docs on getDynamicModifiers for attribute freshing
* player -> user because context is not always a player
* add license to TestNullableItem
# 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 dc716ea167)
* Move command API icon to correct location
* Add client-sided command API
* Add jd note about threads
* Add license headers
* ArgumentBuilders => ClientArgumentBuilders
* Yeet custom prefixes
* Migrate testmod to lifecycle-events-v1
* Improve client command test
* Make client command test more similar to the server one
* Update to new yarn names
* Add handling for requires() in command suggestions
* Remove outdated TODO
* Playerification
* Clarify comments in ClientCommandInternals
* Use "s" instead of "it"
* Improve CommandSyntaxException logging
* Add missing import
* Add /fcc help command
* Add comments about server-client precedence rules
* Add missing license header
* Add /fabric-command-api-v1:client as an alias for /fcc
(cherry picked from commit 871300cf73)
This migrates all uses of v0 networking to v1 api, and changes the readme to not mention networking-v0 in the example for dependencies.
This effectively makes v0 removable if it breaks in the future beyond repair. Though I expect v0 to last quite a bit longer.
(cherry picked from commit bf770ed853)
