Add FeatureFlag API#8952
Conversation
|
How about using |
Deprecated seems inappropriate for this, and scheduledforremoval might work for UPDATE_1_20, but not bundle as we have no clue when that's gonna be removed. I think Experimental is the most accurate marker annotation. |
| JvmProfiler.INSTANCE.start(Environment.SERVER); | ||
| } | ||
|
|
||
| + io.papermc.paper.world.flag.PaperFeatureFlagProviderImpl.INSTANCE.getClass(); // Paper - init FeatureFlagProvider |
There was a problem hiding this comment.
Is this the preferred way we want to inject server singletons into the API ?
I know this is a somewhat long standing issue between services, the server interface and this one.
closes #128 using a temporary workaround while awaiting PaperMC/Paper#8952
Owen1212055
left a comment
Owen1212055
left a comment
There was a problem hiding this comment.
Generally looks good, but think we should wait for the enum PR to allow us to have the "isEnabled" method be implemented manually to prevent the need for instance for the "FeatureElement" conversion thing.
|
Sorry, what exactly is blocking this? I don't see a "enum PR" from a glance, unless you mean the property API tagged "for: future" which I quite hope not... This is preventing me from being able to determine what items/entities are spawnable which is quite unfortunate for my use cases. I worked around it in the meantime with NMS but obviously this is not an ideal solution for cross-version compatibility among other issues. I'm hoping this could just be merged now (ideally to 1.19.4 while it's still supported ❤️) and improved later since it "generally looks good"? |
|
The enum PR was the PR previous thought to be slated by upstream for 1.20. It replaces a ton of the enums and deprecates Material. |
|
Ah, upstream, I can see the hesitation then. Unfortunate but I can live with NMS for the moment if this isn't viable yet to merge. Thanks for the reasoning ❤️ |
|
Would it be an option to extend the API with a method that outputs a permitted This could be helpful e.g. for tab-completions in which only the enabled blocks are to be displayed. Otherwise, you have to check all game objects individually each time. |
Machine-Maker
force-pushed
the
feature/feature-flag-api
branch
2 times, most recently
from
f789ba0 to
4e4d350
Compare
|
Ok, revamped this and took over as much as possible from upstream's feature flag API. Added tests to ensure nothing is missed as well. |
Machine-Maker
force-pushed
the
feature/feature-flag-api
branch
from
4e4d350 to
f95c924
Compare
Machine-Maker
force-pushed
the
feature/feature-flag-api
branch
2 times, most recently
from
11444f2 to
88bf4c6
Compare
Machine-Maker
force-pushed
the
feature/feature-flag-api
branch
from
88bf4c6 to
0bd54cb
Compare
|
you didn't list how we are supposed to fix isEnabledByFeature being marked for removal, what is the new method? |
|
The FeatureDependant and FeatureFlagSetHolder have what you want. A method on FeatureFlagSetHolder to check if a FeatureDependant is enabled. So like world#isEnabled(EntityType.PIG) or smth. |
* Add FeatureFlag API * switch to index & move method * fix test
7 participants
Closes #8950
My initial thoughts on API for checking if a Material or EntityType is enabled with a
FeatureDependantinterface.Adds tests to check on updates when this changes.