Registring LifecycleEvents.TAGS outside of bootstrap.

[tal5]

Is your feature request related to a problem?

Currently LifecycleEvents.TAGS can only be registered inside a plugin bootstrap, even though Minecraft lets you reload tags at any time.
That means the API can't be used by any plugins using the plugin.yml system, and makes it harder to use for any plugins that only have the relevant data post bootstrap.

Describe the solution you'd like.

For LifecycleEvents.TAGS to be available during onEnable, similarly to LifecycleEvents.COMMANDS.
This will technically require an extra Minecraft data reload after plugins enable, but assuming it's possible to make that reload only happen if any plugins actually registered a handler, I don't think that should be too much of a problem? can even make that a configurable thing on the event for plugins that don't change anything immediately & only need a handler for later reloads.

Describe alternatives you've considered.

With Paper plugins it's possible to register a handler in bootstrap that does nothing initially and reload later, for plugin.yml plugins the only way is NMS as far as I know.

Other

See related Discord discussion here.
Thank you to anyone that looks into this!

[electronicboy]

These are just events, nothing more, nothing less; forcing an entire data reload as part of the server startup lifecycle just sounds like an entire headache to push forward something Mojang only seemingly provides a loose level of support for data pack devs, it's not a mechanism intended to be used every day on actual running servers, and so, I really can't get behind this.

Part of the reality is that if you want modern features, we're going to need to adapt to how Mojang actually handles this stuff, rather than trying to fight the current to bodge around how their stuff works

[Malfrador]

Maybe just allow plugins to register tags later, but leave the reloading to them? They can just call Bukkit#reloadData. Not really a fan of automatically doing this on startup.

That wouldn't really require much hacking or go against vanilla handling - its similar to adding tag files to a datapack and doing /minecraft:reload, the only change here would be entirely on the Paper side of things.

[electronicboy]

Yes, they're re-run on a reload but, the important part is that they're also run as part of the normal bootstrapping process of the server where all of this data is properly defined, nothing you added in here would be reliably utilised by datapacks, and I'm not exactly sure that we should be trying to promise any support for what will essentially be modifying the servers bootstrap lifecycle process

[tal5]

In my opinion, since the existing API can already completely modify tags compared to the initial datapack load (I.e. the new API, as far as I can understand at least, wouldn't be changing anything on that front) & datapacks themselves can be loaded/unloaded to change tags at runtime, it wouldn't make sense to avoid adding that just because it promotes the already existing behavior (and for datapack integration it would be the same as the commands event, no? register in bootstrap for datapack support, or can use onEnable if you don't need that).
I get where you're coming from though, as I suppose it does promote that usage even if it already exists - if it won't be added as official API, would exposing a "use at your own risk" be possible, if it's basically the same handling internally? something in Unsafe maybe?

[electronicboy]

completely modify tags compared to the initial datapack load

except it does so in a manner that is compatible with the semantics of mojangs data loading system, which will allow you to utilise these things inside of datapacks, within the bounds of the proper lifecycle of mojangs initialisation process.

it wouldn't make sense to avoid adding that just because it promotes the already existing behavior

Except it's not existing behaviour, Mojang does not double load on startup, and reload is there as util for messing with packs; it's not intended as something that should be part of every single server startup, there is little interest to have to force data to reload multiple times just so that we can fire the event multiple times so that people can interact with stuff.

and for datapack integration it would be the same as the commands event, no?

Just because the existing lifecycle modifications we've adopted from upstream cause some incompatibilities with mojangs lifecycling doesn't mean that we will, or should, go out of our way to bork other parts of the system to support out of band mutating of this data. Just because their reload command exists doesn't mean we should make its invocation part of the bootstrapping process.

[masmc05]

If you're at the level to make an api at your own risk then you may just use MappedRegistry#getOrCreateTag in nms with reflection, basically this

var reg = (MappedRegistry<Block>) BuiltInRegistries.BLOCK;
var tag = reg.getOrCreateTag(TagKey.create(Registries.BLOCK, ResourceLocation.parse("test:test")));
VarHandle entriesVarHandle = MethodHandles.privateLookupIn(
       HolderSet.Named.class,
       MethodHandles.lookup()
).findVarHandle(HolderSet.Named.class, "contents", List.class);
// Content is not final as it's meant to be constantly replaced on each reload, when ServerResourcesReloadedEvent is called
entriesVarHandle.set(tag, List.of(reg.getHolder(ResourceLocation.parse("minecraft:stone")).orElseThrow()));

Same as with just reloading tags, you won't be able to use it in special places like enchantments etc.

It's a bad behavior, with better alternative, not properly supported by minecraft itself and with the potential to not be even supported even by /minecraft:reload in future, so it's really not something for api

[tal5]

That makes sense I suppose, thank you both for explaining - hopefully we'll be able to just properly move over to Paper plugins in the future.
Also not sure if it's that easy on 1.21.3, these methods seem to be different now, but I'm sure I can figure it out.
Regardless thank you both again, will close this now