[1.20.4] Alter StartTracking with Before and After Variants #3696
Conversation
…cking - Keep binary compatibility with the old field marking such as deprecated
...working-api-v1/src/main/java/net/fabricmc/fabric/api/networking/v1/EntityTrackingEvents.java
Outdated
Show resolved
Hide resolved
| * @deprecated Use {#BEFORE_START_TRACKING} or {@link #AFTER_START_TRACKING} instead | ||
| */ | ||
| @Deprecated(forRemoval = true) | ||
| public static final Event<BeforeStartTracking> START_TRACKING = BEFORE_START_TRACKING; |
There was a problem hiding this comment.
I would prob just leave this a tottaly seperate event, and keep it the same as it was before.
There was a problem hiding this comment.
Little clarification, do you mean:
- Keep the original Event as it was but with deprecation while also adding the specific before and after variants
OR - Keep the original Event but add the after-variant as the only addition
There was a problem hiding this comment.
Think it's no. 2; start tracking and after start tracking events.
There was a problem hiding this comment.
Hi, sorry. I was more thinking about 1:
Keep the current event untouched, no need to try and be clever about ensuring backwards compatibility just duplicate it. You would then end up with:
- BEFORE_START_TRACKING
- START_TRACKING (existing, deprecated)
- AFTER_START_TRACKING
There was a problem hiding this comment.
I did ensure the code was backward compatible but made the desired adjustment to the PR.
|
Not sure if this really needs a before variant. After all the point of the event is to sync custom data to the client which is not really possible if the client doesn't know about the entity yet. Forge/Neo also only have the after variant (called at the end of the method instead of beginning). So this PR would probably work just as a bugfix for moving the existing event to the end of the method instead of keeping it at the beginning. |
|
I do agree that this should frankly be just a change to push the injection of the mixin invocation at the tail of the method. Unless someone has a reason for the original behavior which doesn't seem likely. |
The Point of this PR is to have an After Variant for StartTracking as the current implementation calls the
StartTrackingevent before any packets for the Entity's creation making such an event pointless if you need to sync things like data attachment to the Client as such will require some delayed method of handling any packet sent until the entity exists. Evidence of such an event being useful can be found within Cardinal Components and NeoForge.Additionally, this PR attempts to keep binary compatibility with previous API versions with such old variants extending the renaming of the old event.