Skip to content
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

Open
wants to merge 2 commits into
base: 1.20.4
Choose a base branch
from

Conversation

Dragon-Seeker
Copy link

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.

…cking

- Keep binary compatibility with the old field marking such as deprecated
Copy link
Member

@modmuss50 modmuss50 left a 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.

* @deprecated Use {#BEFORE_START_TRACKING} or {@link #AFTER_START_TRACKING} instead
*/
@Deprecated(forRemoval = true)
public static final Event<BeforeStartTracking> START_TRACKING = BEFORE_START_TRACKING;
Copy link
Member

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.

Copy link
Author

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:

  1. Keep the original Event as it was but with deprecation while also adding the specific before and after variants
    OR
  2. Keep the original Event but add the after-variant as the only addition

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants