* 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)
* - Add new method AttachmentRegistry#create that allows configuration of the registered attachment type with a builder.
- Migrate existing creation methods to use the new one under the hood for consistency.
- Moves all null checking from AttachmentRegistry to AttachmentRegistryImpl.BuilderImpl (most of them happened there as well already and were thus redundant).
* - Adds the ability to initialize an AttachmentType with only a path, substituting the mod ID of the registrant via an entrypoint.
* - Add registration safety checks
* - Add missing copyright header
* - Remove lazy entrypoint initialization of attachment types.
* - Import fixes
* - Update javadoc.
* - Use expression lambdas.
* - Fix style checks
* - More style fixes
* - Fix line endings
* - Move WheelInfo and initialization to test package
- Deprecate AttachmentRegistry#builder
- Update existing tests to use #create rather than #builder
(cherry picked from commit e49211d8c6)