* Update Model Loading API to 1.21.4
- Split model modifier events and callbacks - one set for static models and one set for block models
- This is necessary because static models use UnbakedModel and are baked with settings while block models use GroupableModel and are not baked with settings
- This cleans up the Identifier/ModelIdentifier getters
- OnLoad for block models was not added because the unbaked block model map is not a cache and block models cannot inherit from other models
- Make DelegatingUnbakedModel a record to allow accessing the delegate ID
- Remove BuiltinItemRenderer, BuiltinItemRendererRegistry, and BuiltinItemRendererRegistryImpl as they were replaced by a TAW to SpecialModelTypes.ID_MAPPER
* Add fabric_ prefix to methods in BakedModelsHooks and fix checkstyle
* Remove ModelResolver and BlockStateResolver
- The functionality of ModelResolver could be perfectly replicated with ModelModifier.OnLoad with OVERRIDE_PHASE
- The functionality of BlockStateResolver could be perfectly replicated with ModelModifier.BeforeBakeBlock with OVERRIDE_PHASE
- Fix log warning caused by half_red_sand.json not defining particle sprite
* Re-add BlockStateResolver and ModelModifier.OnLoadBlock
- BeforeBakeBlock runs too late to allow modifying how models are grouped, so OnLoadBlock is necessary to allow that
- OnLoadBlock only runs for models which were actually loaded from blockstate files, so BlockStateResolver is necessary to allow adding models for blocks without a corresponding blockstate file
- Add UnwrappableBakedModel
- Moved and renamed from FRAPI's WrapperBakedModel (original will be deleted in separate PR)
- Implement it and interface inject it on vanilla's WrapperBakedModel
- Add new static UnwrappableBakedModel#unwrap method which accepts a Predicate saying when to stop unwrapping
- Add WrapperUnbakedModel which simply delegates all method calls to a different UnbakedModel
* Remove ModelModifier.*Bake*
- Remove BeforeBake, AfterBake, BeforeBakeBlock, AfterBakeBlock
- Remove DelegatingUnbakedModel
- Add WrapperGroupableModel
- Add documentation and extra constructor to WrapperUnbakedModel
* Clarify OnLoad doc about meaning of null model
* Add BEFORE_TERRAIN world render event
* Add 1.21.2 rendering issue warning
* Add comment to injection point
* close b tag
* Undo all new event changes
* Move AFTER_SETUP event to new mixin
* Remove event interface
* Refine mixin
(cherry picked from commit 69228316a9)
Completes the data attachment API with client-server syncing capabilities.
## Motivation
The existing API works great for attaching data to game objects, be they serverside or clientside, but lacks any ability to synchronize between the two.
A mod that wants to add a "thirst" mechanic can easily do so on the server side by attaching an integer to every player. However, the mod may also want to use this information to render additional HUD elements on the client. Currently, informing the client of this data can only be done manually, which is cumbersome, error-prone, and is much better-suited as an API feature.
## API Changes
The API doesn't change a lot (at least compared to the implementation), with a few new methods and one new class.
One new method has been added to `AttachmentRegistry.Builder`, namely `syncWith`. It declares that an attachment type may be synchronized with some clients, and takes a `PacketCodec` to encode attachment data over the network, as well as an element of the new `AttachmentSyncPredicate` interface.
This interface extends `BiPredicate<AttachmentTarget, ServerPlayerEntity>` to allow for user-defined predicates, and provides some common presets:
* `all()`: attachment data will be synchronized with all clients (that track the target).
* `targetOnly()`: attachment data will only be synchronized with the target it is attached to, when it is a player. If the target is not a player, it won't be synchronized with any client.
* `allButTarget()`: reverse of the above. For non-player targets, attachment data will be synchronized with all clients.
**NOTE**: for a user-defined condition, whether attachment data is synchronized with a client can change at runtime (e.g. "sync only with operators" when a player changes operator status). A specialized method to "refresh" data was considered, but in the end discarded due to complexity. It falls to individual mods to handle these edge cases.
AttachmentType also gets one new `isSynced` method to know whether a given attachment type can be synced.
## Usage
Here is how one could register an attachment for a "thirst" meter like mentioned above.
```java
public static final AttachmentType<Integer> THIRST = AttachmentRegistry.<Integer>builder()
.initializer(() -> 20) // start with a default value like hunger
.persistent(Codec.INT) // persist across restarts
.syncWith(PacketCodecs.VAR_INT.cast(), AttachmentSyncPredicate.targetOnly()) // only the player's own client needs the value for rendering
.buildAndRegister(Identifier.of("modid", "thirst"));
```
* Add a new chunk generate event, fired alongside the chunk load event when a chunk is first upgraded to full status
* fix style
* Add logging test for generate event
After creating an SP world and waiting for all nearby chunks to generate (logging to stop), closing the SP world and opening it again should not log any fresh generation. Moving to an unexplored area will start logging again.
* Optimize screenshot delays
I've done multiple test runs on GitHub Actions and this seems to be as low as the timings can go while still reliably generating all of the screenshots correctly.
* Increase wait interval in waitFor to 50ms
* New translations en_us.json (German)
* New translations en_us.json (Italian)
* New translations en_us.json (Russian)
* New translations en_us.json (Polish)
* New translations en_us.json (Russian)
* New translations en_us.json (Korean)
(cherry picked from commit 7fd48375f5)
