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
Add Halloween API #10639
base: master
Are you sure you want to change the base?
Add Halloween API #10639
Conversation
- int j = localdate.get(ChronoField.MONTH_OF_YEAR); | ||
- | ||
- return j == 10 && i >= 20 || j == 11 && i <= 3; | ||
+ return org.bukkit.Bukkit.isHalloweenSeason(); // Paper - Add Halloween API |
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 much rather we not redirect mojang calls into replacements from the bukkit singleton
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.
Implementation is the same, plus forced enable/disable. The patch should fail in case vanilla changes anything.
Not overriding these kinda makes half of this API (forcing/disabling Halloween) obsolete.
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 generally in the long run want to start moving away from the Bukkit/Server "god" class, and so would generally prefer that we don't move implementation aspects to it
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.
What would be the alternative?
Without it, plugins won't have a common ground to communicate, and in this case it makes no sense to enable/disable Halloween and yet have no according behavior changes.
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.
Create another class and proxy the calls to that; maybe others on the team won't care as much, however
Is this really needed in the API? This can be re-created in a plugin easily. |
Agreed |
Depends. You need to duplicate the perfectly working vanilla system (having another time check, changing equipment on some entities, controlling bat's spawn rules and keeping track of changes in the future) while also not having any communication with other plugins. I'd love for plugins to be able to add features during Halloween while also providing a ground to control it from one place (Paper's a good source to depend on, unlike some obscure plugin). I don't think maintaining this is much of a pain. |
Allow checking / forcing Halloween Season/Day via API.
Also makes a tiny optimization over vanilla by using the month/day ints directly (they are stored in fields) instead of fetching from enum.