-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.20.4] Alter StartTracking with Before and After Variants #3696
base: 1.20.4
Are you sure you want to change the base?
[1.20.4] Alter StartTracking with Before and After Variants #3696
Conversation
…cking - Keep binary compatibility with the old field marking such as deprecated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a reasonable change, could you also add some tests for this please.
...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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think it's no. 2; start tracking and after start tracking events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
StartTracking
event 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.