Registry Modification API

[upper plover]

PR: https://github.com/PaperMC/Paper/pull/8920
Gist: https://gist.github.com/Machine-Maker/2901c790219862ef1ad6070b8872a889

This API is for changing tricky-to-modify parts of objects in registries like explosion resistance for blocks, armor toughness for different item types, default loot tables for blocks, game event radii, etc. These properties, traditionally, are immutable and annoying to change without doing some hacky reflection to change final fields or replace registry entries. This API provides a way for bootstraps to change or even add registry entries before they are even in the registry eliminating all hacky registry unfreezes or final field modification. Read a full write up on it here and then look at an example of it being used below.

Example

This modifies a GameEvent to have a larger radius, and adds a new GameEvent.

static final TypedKey<GameEvent> NEW_EVENT = GameEventKeys.create(Key.key("machine_maker", "best_event"));

@Override
public void bootstrap(@NotNull BootstrapContext context) {
    final LifecycleEventManager<BootstrapContext> lifecycles = context.getLifecycleManager();

    // registers a new handler for the prefreeze event for the game event registry
    lifecycles.registerEventHandler(RegistryEvents.GAME_EVENT.preFreeze().newHandler(event -> {
        // the RegistryView provided here is writable so you can register new objects
        event.registry().register(NEW_EVENT, builder -> {
            builder.range(2);
        });
    }));
    
    // registers a handler for the addition event
    lifecycles.registerEventHandler(RegistryEvents.GAME_EVENT.newAdditionHandler(event -> {
        // checks if the object being registered is the block open game event
        if (event.key().equals(GameEventKeys.BLOCK_OPEN)) {
            event.builder().range(event.builder().range() * 2);
        }
    }));
}

[grim dust]

Getting closer and closer to mods

[hoary plume]

If only this was around a couple of weeks ago

[molten notch]

will this finally allow non-hacky ways to register custom enchants?

[boreal zodiac]

Seems so, unfortunately I am afraid that those still will need manually added description to lore :-/

[molten notch]

that can be done with packets tbf

[upper plover]

yeah, that is a definite possibility with this system. There are some special considerations with enchantments, like they can't be used as enchantment table hints, but its way more of a possibility

[candid steppe]

My initial question would be why this freezing is a thing in the first place. Is there a specific reason why it would not be possible to modify the explosion resistance when the server is properly running?

[molten notch]

^

[upper plover]

if a registry ever uses the numerical id for something, special care needs to be taken if we allow adding new elements

[upper plover]

well, it seems more and more registries are being synced with the client. this would be one huge reason

also, if anywhere in the server some field held an instance of an object from a registry, and you replaced that with some other object, you could have problems

[rare canopy]

Updating things on the client isn't out of the question, it just requires going back to the config phase, the other question is how well the server handles that state

[vestal cairn]

Does this api also contain builders for datapack driven registries? Like biomes?

[candid steppe]

Well, if it can be made to work with the client, then I think the overall better approach for an API would be doing this. As for holding instances, yes that is a problem, but then I think an event or something that could notify that this is about to happen would be better as this can then be handled.

[sacred current]

The freezing occurs because thats at the point in which those registries are effectively static and then somewhat "cloned off" is my understanding of the code from a while back

[split wolf]

Replacing Registries at runtime is not the use case of registries.
And like Machine Maker said more and more stuff is being synced to the client.
And sending a player back to config phase is likely not ideal, because in that case why not just restart?

[sacred current]

The current thing is a bit of a mess given the thing is somewhat further mangled by upstream

I mean, for stuff like dev time it can make a lot of sense assuming that you can work within the limitations of what mojangs reload allows

mutating registries past that is generally a headache which I really doubt we want to deal with as then you need to start arbitarily defining what is safe to mutate and reset when they relog, what can wait until some specific action, i.e. on dimension change, and then what is pretty much a "if you touch this, you have to reset clients now"

[candid steppe]

Well, I imagined you'd always reset clients if you make changes to a registry. And as for why not restart, restarting the entire server seems like it'd do far more than just reset players back to the configuration phase as all your plugins would also restart.

[upper plover]

right now, it only contains a builder for GameEvent. But once the basic framework is solid, adding more builders for more types is not very difficult

I wanted to demo with a simple type, not one of the most complex like Biome

[sacred current]

depends on what's changing, part of the headache is that iirc, some registries basically end up devolving off from the main registrys

but, I'm not 100% on that, it's been some time since I last looked at that code, and generally, mojangs been evolving that slowly over the years too

promising any form of runtime ability to mess that stuff is somewhat of a nogo imho

[split wolf]

I would say that this is very unsafe.
The added benefit of such a system is similar to a reload plugin system.
It might be more convenient, but imo will result in an unstable system.
To make such impactful modifications a server restart is understandable imo.

Oh god I wrote to many "imo"

[rare canopy]

Most vanilla registry code has been rewritten to make sure references aren't held onto, but just "holders," inviting you to reload them

it probably won't go all the way, but it's not entirely unsafe

[upper plover]

I don't think this system makes it so runtime modification is impossible, on the contrary, builders and TypedKeys are 2 components which would be needed for such a system anyways. But I also don't think its one or the other, and starting with modifying them at the very beginning I think is the right move

[split wolf]

I know, what I meant is that we don't know how it will evolve.
And while mojang is making hugggee changes to the registry system.
(Blocks getting datadriven, and so on)
I wouldn't add such a mechanic which might turn out to be really bad in retrospective.

[ocean musk]

Not sure if I get this right... But this API would allow us to modify aspects of blocks and items too? Like applying certain hardness, dig-speed, etc to them.
Like a prime example I would give here is plugins like Nova using note blocks for custom blocks, and this allowing them to apply custom attributes to these blocks now...
I may understand this wrong tbh...

[flint summit]

Would be possible to change the hardness of a material with this new api?

[split wolf]

Breakingspeed isn't yet synced to the client.

[flint summit]

Oh well, thats unfortunate

[candid steppe]

Well, I'm not against the idea of having a basic "first start" and then expanding it later, but it seems like this would introduce API that would not be necessary if, at some point, you can modify registries whenever you want. For example, the registry pre-freeze event wouldn't be a thing if you can always modify registries. So this first start would introduce API that would be broken again if you extend it.

[sacred current]

Basically, mutating registries at runtime is an entire rabbit hole of which might not be 100% tenable

some registries support it much better than others, it's not something we can promise and I don't think that runtime mutation would ever really be the supported mechanism outside of it maybe existing and it being your own foot

[molten notch]

is the issue with mutating registries that it needs to resend the clien to the config phase?

[split wolf]

Yes that is one of the problem

[molten notch]

that would entirely be on the plugin developer, no?

[split wolf]

Second is that we don't know what mojang will be doing.
We shouldn't tap into such hot waters

[sacred current]

theres an entire bunch of lifecycles tuff in the server that occurs

pretty sure that they still have logic for copying registries

[alpine trench]

for me personally this sounds like the reload or restart thing when applying plugin changes

[molten notch]

im thinking in the context of cases where I need to init something 1 tick after the server starts because stupid shit like that happens from time to time

[split wolf]

Well if we add an api and make it easy to use, people will use it as an easy solution even if registering it in the right time would be better

[sacred current]

From what I saw, it did look like they where kinda looking into isolating some aspects of the registries into being a per-dimension thing, which is part of why I wonder why they added the config phase outside of being nice to proxies

[split wolf]

Could you name a scenario?

[vestal cairn]

Looking forward! 🙂

I was just thinking about a technique to change the block hardness.
Since it will result in buggy behaviour to just change block hardness you could send a mining fatigue packet to the player with no particles or ambient. Then you send the block break status as a packet. The same packet that is used to broadcast the damage state while digging to other players.
When a block has custom block hardness this logic could take over the block breaking logic. I think it would be nice to make this also possible

[sacred current]

Well, that is not sync'd to the client

you can decrease the hardness fine, you can't increase it however

[rare canopy]

For now that is

[split wolf]

Yes

Will likely change

[candid steppe]

I think it'd make more sense to first see if there are actual registries for which there is absolutely no way to safely change them and only introduce this freezing if that's actually the case.

[molten notch]

well no cause this isnt an actual implemented API, I havent used this API, I know i've had previous situations where ive needed to init shit like 1 tick after the server starts. Regardless, this should be a decision made by the plugin developer, as long as im given the option to resend players registries then im good

[vestal cairn]

I wrote some code as proof of concept and it works.

That is why you use those packets to trick the client

[molten notch]

that sounds like the job a plugin rather than a paper api

[split wolf]

I wouldn't just say that might be needed at somepoint sometime.
Such a brittle system as registries are in such a limbo state with mojang likely changing a huge amount about it is not something I would add hotswapability to.
If you want to replace the registry fine do it.
But I think just putting it into this api might create a bit of a who cares, even if the right and more stable way would to register the stuff at the right time.

[sacred current]

I mean, resetting registries would basically be like a Player#resetClient()

that entire mechanism is still moving

right now you'd lose your texture packs, etc

[molten notch]

if the registry is reset 1 tick after startup, it wont really effect players, at most someone whos hotloading plugins which I dont think anyone cares if they get another resource pack send

[sacred current]

it affects the server

[split wolf]

And I don't think that their is a need for something like this.

At least I can't think of one.

[atomic snow]

custom enchants?!

?!!??!?!

[upper plover]

so if we dont want to introduce the concept of freezing, but also don't want to (right away) allow mutation after they are frozen, we would need some other way for plugins to add new entries (where supported). The addition event stays, but that doesn't provide a way to add new entries.

[silent vortex]

That would be my main concern here as well. With the config phase, vanilla seems to be going into the direction of "registries can change during gameplay". So I wouldn't be too surprised if more registries end up being reloadable with /minecraft:reload.
And it would be very unfortunuate if this API ends up in the same state as Bukkit right now, being less flexible than datapacks for registry stuff in a few years

[upper plover]

I don't really see how a freeze event now would prevent supporting that modifiability during runtime later

we would just continue firing the freeze event in the same place, and then just add api to modify or add entries whenever

being reloadable with /minecraft:reload.
I do not consider this "editable during runtime"

if they do this, they'd have to kick all players back to the config stage, and that, to me, is as good as a full restart

modifying during runtime would be like: player clicks a button, new entry added

[silent vortex]

for the players yes. for plugins no, they aren't even reloaded with the minecraft reload

[upper plover]

that doesn't matter. You are registering event handlers that can just be run again when a registry is "reloaded"

that's why they are events, so they can be called multiple times.

[silent vortex]

My understanding was that the plugin bootstrap is only happening once, when the plugin is loaded, and that the registry events are only available during the plugin bootstrap

[upper plover]

registering the event handlers is only available during bootstrap

but those handlers can be called whenever

you add an event handler to modify a game event's range during plugin bootstrap. If the game event regsitry is reloaded, we can just call that handler again

[silent vortex]

oh well, then that wouldn't be an issue, alright

[upper plover]

and if reloading registries does become a thing, it might be prudent to allow registering of handlers outside of the bootstrap. but that isn't now and can be done later if needed

[jade jacinth]

im assuming this would also allow you to change a weapon's damage or attack speed & nbt things like adventure mode tags you can't traditionally change that easily

[upper plover]

adventure mode tags? that's just on the itemstack. we already have API for that

if you mean the CanPlaceOn and CanDestroy nbt tags

[jade jacinth]

yes

[silent vortex]

and weapon stats are attributes, those can also be changed already

[upper plover]

yeah

[silent vortex]

though the default values for those are part of the SwordItem constructor in the Item registry

[upper plover]

yeah, it would allow changing of those defaults (once a builder for that item type is added)

[grim herald]

I’ve been waiting for ages for this

custom biomes soon?

[keen kelp]

You should start with the thing you know works, not add something then have to pull it after people try to use it because it doesn't work

whoops, wasn't meant to ping

[candid steppe]

No worries, I don't mind pings

[deep stream]

if i understand correctly, this means i can have a custom item with a custom key added into the item registry, and commands like /give can use the custom key?

[sacred current]

no

mojang does not support custom items

[deep cradle]

yet

[sacred saddle]

But we got a step closer with per plugin resource packs

[sacred current]

that's literally irrelevant

until mojang adds support for custom items to the client, and they make it a sync-able registry, it's literally useless to be able to add stuff to that registry

[sacred saddle]

I mean you need to add a texture for the item so a plugin resource pack is an important step

Obviously useless now but still

[mental perch]

Huh

Could this API be used to, for example, modify the maximum Item Stack Size of a given item?

Or, change the time it takes to eat a piece of food?

[upper plover]

probably not very well. both of those things, the client makes lots of predictions about

[mental perch]

I see, but it could help the servers doing the first thing, right?

[sacred saddle]

As long as mojang doesn’t support it on the client it doesn’t matter

[sacred current]

if that aspect is exposed, yes, it could

[deep stream]

So anything that can be modified server sided via datapacks will have a modifiable registry

achievements, world gen, structures, biome etc...

and not items

[sacred saddle]

Custom achievements would be insane

Also structures

[heady inlet]

until they do this, couldnt you manipulate the packets so it appears as an item that already exists with custom model data?

[sacred current]

I mean, sure

you can also shoot yourself in the foot

We will not be writing API for that, however

[astral grove]

will this let us change tools base efficiency serverside without any need for client modifications?

[sacred current]

I have no idea what's exposed in the thing right now, I'm half dead and struggling to keep up

but, basically, no

Like, the API might offer the means to manipulate that sorta stuff, but the item registry is not sent to the client, and so if you mess with that stuff, it's not going to know about it

and that's before you get to the point that a bunch of this stuff is just not part of the registry definition yet but is hard-coded into the item classes, etc

[deep stream]

this can alr be done right now

with alot of nms and reflection

[sacred saddle]

The goal is to minimize the need of nms

[heady inlet]

well yeah, a lot of things can already be done with nms and reflection, but adding proper api for them means you dont need either of those

[deep stream]

ah oops.. i thought you didnt know xd

[sacred saddle]

But the sad thing is that people just use NMS and don’t try to expose things for everyone and easier use…

[deep stream]

that. is true.

[foggy finch]

Official api is always better then having to NMS shit

[vestal cairn]

Is the CraftRegistry and Bukkit Registry API about to change?

Especially when looking at Bukkit api representations that are enums right now. (Like attributes, VillagerProfession, etc...)

[upper plover]

Yeah, upstream has a big pr to remove all the enums that have registries

Material, EntityType, etc.

[heady inlet]

wait, the bukkit material enum is going to get removed?

[sacred current]

yes

enum makes 0 sense long term

[heady inlet]

never thought id see the day

long live registries!

[boreal zodiac]

It seems that upstream yeeted registerEnchantment method and started sourcing enchantments from registries... which is overall good, but before Registry mod api is merged I guess there is no way to register enchantment now? Or is there a hacky way to add an item to a registry?

[upper plover]

Yeah, use nms if you want to do that

[stoic crystal]

Actually it is useful when making custom stuff with nms.
Some time ago I managed to create a custom pufferfish entity, that didn't move.
I added the entity with reflection to the registry.
I extended the pufferfish's class and in the method where it's data is saved to nbt I also overwrote the id field

nbt.putString("id", "minecraft:static_pufferfish");

This way I got a custom entity that minecraft server can save and then load properly without string it somewhere else, but that appeared to client as a normal looking pufferfish.
So I think an api for modyfing other registries could be useful for some more advanced coders when combined with nms.

[sacred current]

except we cannot support it

there is no sane justification to support it outside of "people hack with internals anyways"

and, so, the general stance is is that until we can officially support it, they can keep hacking

[dense nova]

Stuff like polymc / polymer is the fabric server-side space is interesting since it basically is still a modded server, just everything different are wrappers with a "client" representation, which maps it to vanilla stuff client side only

Paper has way too much legacy API stuff for that to be possible ATM, but who knows, might be cool for the future

Sorry, little off topic from the API here

[mint carbon]

With this API would it be possible to register new damage sources, and if so how would we control the lang keys?

Or would you have to make a resource pack?

[sacred current]

You would need a resource pack if you wanted to use lang keys

[mint carbon]

Well it’s not really a “wanted too” just a have too because of how the damage source registry works

[sacred current]

I mean, afaik, the API literally doesn't even support the vanilla damage source stuff

and so custom stuff is generally out of the window

idk if the API will let you register them right now, but, it theorietically could

just, they'd serve no use as-is

[mint carbon]

Gotcha

[vernal scroll]

There's a separate PR open for proper damage source API iirc

[mint carbon]

I looked but I couldn’t find it, any chance you could link it?

[maiden stirrup]

https://github.com/PaperMC/Paper/pull/8058

[brisk kettle]

Does this api allow us to add PotionEffectType?

[dense nova]

no i think: the only client synced registeries are https://wiki.vg/Registry_Data shown here
i could be wrong tho

[dense nova]

actually im 99% sure im wrong, but im not sure what the client does with potion effect types it doesnt know about

[dense nova]

potion effects are ints over the wire, so it doesnt like changing that registry

[rare canopy]

Yeah, this API doesn't really allow you to do a lot of exciting things just yet, mostly in anticipation of a lot more things becoming data driven

[dense nova]

i havent looked loads into this, but tags are a registry right? does this pr allow adding block/item tags?

or is this just the base

[rare canopy]

Tags are different to the other registries, they're sent separately and can be updated during gameplay as well

there's already API for that I think

[dense nova]

oh am i just stupid, thats fair

looking at javadocs, i see a material set tag? idk if that includes adding tags a member, or if thats a datapack only thing that flattens

[split wolf]

Theoratically with this a polymer-like library could be implemented, right?

[heady inlet]

#1179518554702348319 message

[dense nova]

it would be harder than needed i think to do it with packets, compared to actually modifying the handlers / implementation

especially where its not a 1-1 map, like to set a block, you need to set a barrier and spawn a block display entity (eg), as well as track state

[heady inlet]

for blocks, yeah, but items are probably not that hard to do that for

[brisk kettle]

ty for the link

[floral stone]

What if we had a client mod for this that syncs the modded server registries with the client

[dense nova]

I mean I guess you can implement the forge/fabric sync protocol server-side

Out of scope for paper tho, and it would break vanilla client compat

[split wolf]

We cant sync registries. They are frezzed after being registerd. We can conly sync the dynamic Registries.
The only thing we can do is mod the game on both sides and maybe implenent registry sync to be sure that registries are properly synced

[sacred current]

It's simple: paper does not support mods, and so, we do not make API which requires mods to be useful

[brisk kettle]

does this api allows us to add advancement?

[sacred current]

You can already add advancements?

[vestal cairn]

Things that we might want to add are

MemoryModuleTypes
Brain Sensors
Villager Professions (yes they wont have a specific look then but anyways)
PoiTypes
Attributes (non synced)

And what i really need is a way to add loot tables via api

I dont like editing those files

[sacred current]

Well, biggest issue for advancements/loottables was the lack of code gen, writing API around mojang data types is not something we can promise, but that's part of what the api generation stuff aims to solve, it just won't have the whole promises around API versioning, etc

a bunch of that having the means to mutate in the registry would mean nothing, we need useful API for it to be implementable and usable

there is no brain API, and so having the means to register them in the registry right now is effectively useless

[brisk kettle]

there is already api for that?

[sacred current]

Yes

kinda

[brisk kettle]

damn, sorry then

[sacred current]

it just lets you throw a blob of json at it, so it's not real API as such, but, it's doable

[brisk kettle]

this thing right? https://jd.papermc.io/paper/1.14/org/bukkit/UnsafeValues.html#loadAdvancement-org.bukkit.NamespacedKey-java.lang.String-

[sacred current]

Yes

[brisk kettle]

great, ty very much

[vestal cairn]

I am currently working on a brain api. But to make it useful i implemented a custom behaviour. In addition i made a "behaviour factory" like class where you could create vanilla behaviours. In case you want to recreate villager AI you can fully rebuild it with your custom behaviours.
I also created a mob goal factory to be able to create mob goals with your own parameters.

But i don't know if that is way to specific to be a PR

[sacred current]

In addition i made a "behaviour factory" like class where you could create vanilla behaviours

We want that sorta stuff to be auto-generated

[vestal cairn]

Yeah i know

I will use the api on my own until paper gets a proper generated api for that

[sacred current]

but, there is general interest in having APIs around stuff like the brain

I'm not 100% fond of the way mojang has designed that stuff, and I believe that others had the same sorta concerns around how hard-coded some avenues are

[vestal cairn]

My main concern with this is performance. Especially villager AI takes so much performance. I wonder what needs to be done to make it way better

[sacred current]

Easiest solution for villagers is generally going to be "dummer AI"

But, that's offtopic

[vestal cairn]

true

[bright owl]

@vestal cairn Fyi, https://github.com/PaperMC/Paper/pull/6968

[fresh crescent]

With this api, and new components from 1.20.5, will we be able to change the default components of items that are defined in the items from the item registry?

[boreal zodiac]

I think the item components are separate thing. Those components relate to current ItemMeta data so after this change when paper accommodate to this you can change this data without registry modification...

(correct me if I'm wrong, please)

[rare canopy]

Correct

It'll probably need lots of changes/fixing because basically any of those itemmeta interfaces can now apply to any item

[sacred current]

default components

I feel that aspect was maybe missed?

[rare canopy]

Ah well

[sacred current]

Like, ItemMeta will let you modify stuff on created stacks

[boreal zodiac]

So like default values for "ItemMeta"?

[sacred current]

that's what I seemed to take their question as

think stuff like combat mechanic plugins

[boreal zodiac]

I am interested in latest component updates that let you set max stack size beyond 64, edability of items etc... Will this be eventually possible without modifying the registry?

[sacred current]

Yes, that's a component defined on the item

[rare canopy]

Actually yeah, as simple as calling a method on itemstack

[sacred current]

that would either be itemmeta or properties API

[boreal zodiac]

Nice! For me that is one of the top changes of 1.20.5 😁

[fresh crescent]

I meant those components

those are currently built in and hard coded

[rare canopy]

Nope, you can change them at any point

[sacred current]

Basically, in terms of the registry, that is where the defaults would be modified, yes

[bright owl]

generally that whole concept is separate from this API

[sacred current]

but, if that registry is not sync'd, then you can't really modify them

[bright owl]

“Default” values are not part of the component, it’s defined as per the component map created from the item. (So they may be set to default value on creation)

There isn’t really anything related to registries with all of this.

[sacred current]

Item is an element in the registry was my understanding/thought here

[rare canopy]

Nah

Well the datacomponent types themselves, but that's not really relevant

[bright owl]

Yeah that’s why, that whole item API isn’t really related to registries at all here

[sacred current]

public static final DefaultedRegistry<Item> ITEM

[fresh crescent]

items are part of the registry, and item stacks copy the item components and those acts as the default values of the component map

[rare canopy]

I can imagine default values being moved to a synchronized item registry in the future, but even without that you can just modify it after creation

[sacred current]

They are talking about the defaults is my understanding, that is what they want to modify

the caveat here si as I said is that it's not a sync'd registry, and so you can't really do anything reliable in terms of modifying the defaults right now outside of server-only sided stuff

[rare canopy]

There's only few things the client relies on via the inbuilt item registry

almost everything is server side or at the very least modifiable by the server

[bright owl]

Yes well item modification stuff like this is something we want to do yes

But not related to data component stuff, at least yet.

[sacred current]

the defaults are stored in the registry, that is my understanding of what they want to modify, it's just not sync'd, and so there is not a real use of modifying the defaults

ItemMeta will let you modify the per item overrides, akin to what it does now

[bright owl]

What defaults are we talking about here

The default set data components on items?

[sacred current]

Yes

[bright owl]

Okay

[sacred current]

Like how diamond_pickaxe will likely have a default component which sets the damage for that item type

[bright owl]

Yes well, all that of course being able to customize those default components is part of the big picture

Since for example this api is meant to cover like overriding biomes or such, or block properties

[rare canopy]

The default values aren't default in so much as "if I have an item and check for damage, it will get the default from that type" but the default populators

everything will always still be written and send, so you can still successfully edit the defaults if you really needed to (ignoring creative mode lol), though I dont think there's much of a point in having api for that at the moment

[sacred current]

oh, so like, the entire thing is sent, even the default stuff?

seems wasteful, but, well, that does let you mess with the defaults, which would be registry related, like, it's all shoved into a registry

[rare canopy]

actually maybe I'm wrong idk but yeah as you said, it still kinda needs the synchronized registry part, until then it's just modification after creation on any individual item

[fresh crescent]

not everything is sent, itemstack has a PatchedComponentMap (or a similar name) and it remembers the modifications as a "patch" which is sent

[bright owl]

Yeah no smh Kenny you are WTONG

Yes not everything is sent

[sacred current]

so, yes, in order to mess with the defaults you'd need to mess with the Item element in the registry

BUT

[bright owl]

So the issue is it’s simply not possible to override defaults without syncing the default item components

[rare canopy]

There was a funny issue in the snapshots with goat horns where if you give yourself one, it won't play any sound cuz no default, that's where that came from

[sacred current]

that data is not sync'd to the client, and so there is no reliablility here in terms of what you can modify

[bright owl]

DOOT DOOT

[sacred current]

Like, you could set the default lore, but, the client will never see it

[fresh crescent]

we can just make an item with a patched map and copy the patch map to itemstacks, since it already has a mechanism of copying the patch map at write

so we can just pass the same reference2objectmap from the item everywhere with the copyOnWrite as true in the patched map

[bright owl]

That’s hacky tho, like it’s really better to wait here for proper support here

[rare canopy]

ok lol it's not even the first time for that same exact item https://bugs.mojang.com/browse/MC-251350

[sacred current]

gg

[keen kelp]

I think the ask is to duplicate the Item registry so you have the vanilla one and the modified one and can automatically non-"default" any of the modified default components then they would exist in the itemstack and be sent to clients

[upper plover]

I was thinking about something similar, a system that added “patches” to change stacks to the new defaults whenever a stack was sent to the client.

I think there is substantial benefit to such a system, as it lets you change all itemstacks at once.

[rare canopy]

With the assumption that items will be registry synced that just means duped API

[upper plover]

Wouldn’t we just have to re-implement the same one? It’d be done via registry modification of the items registry and the default components, but we’d have something extra for this

[sacred current]

I'd imagine that you'd ideally design it so that, for now, we abuse patching

in the future we'd then just make it backed by actually modifying the real defaults

[keen kelp]

Oh if you just patch it into the ItemStack codec that would keep it out of anything poking at NBT on the server and make it easy to remove later without clogging things up in file storage

[upper plover]

Yeah, I think that’s what I’m proposing

[sacred current]

but, idk how that patching stuff works

[keen kelp]

Although unless your registry modifications are saved to the level.dat or something that would mean if you ever load the world without the plugin things go bad

[upper plover]

The stacks just wouldn’t have the changed defaults, what’s wrong with that?

[keen kelp]

Well, if you actually edit the ItemStacks instead of just changing the codec then everything would just work

So, tradeoffs

[upper plover]

I'm not understanding what you think "would go bad"

[keen kelp]

Patching the codec makes it look like you can actually change the registry, editing the ItemStacks makes things keep working

You'd just have a pile of useless items

[upper plover]

well they would fall back on their default components, yes

but I don't think that is a problem

just like removing a plugin that adds custom mechanics isn't "bad", it just stops it from working how it did

if you have a plugin that changes the default durability for pickaxes to be multiplied by 5, then if you remove the plugin, all the pickaxes go back to their vanilla defaults

I think that would be expected behavior

[rare canopy]

That breaks with creative clients

as much as I'd love to pretend creative mode weren't literally the worst thing in all of mc, it unfortunately is

[upper plover]

Ugh, I did forget about that

[keen kelp]

Creative breaks the ability to edit this stuff at all, really

Or, well, it makes creative real weird

But since creative can also just make up items with their own component setup you could just ignore that

Like, a sand block a creative user pulls out of their ass wouldn't have your changes on it unless the server went out of its way to modify things from the creative set slot packet but they don't need tools or food or stacking or any of this anyway

And if they do they can just make their own

A creative user copying one of your itemstacks would create actual components on the thing since that's what the client sees but that's fine too, just means that itemstack won't update if you change the defaults in your plugin later

Again, the creative user could have just changed those things anyway

[fresh crescent]

I'll just leave this idea here https://pastebin.com/Lb27qF1P

[crude reef]

when this getting merged?

[heady inlet]

when its ready

there is no eta

[crude reef]

ayeeeeeeeeeeeeee it got merged!

🎊

[eternal nimbus]

🥳

[upper plover]

So yeah, the modification API was merged initially supporting adding/modifying game events and… the big one, enchantments.

[upper plover]

I'm going to post this here, as this ties into this API https://gist.github.com/Machine-Maker/2bc29c2d5468a276ceab1d8c10925d0f

Basically, to unlock the full power of custom enchants, you also need to modify some vanilla tags. for example, for your enchant to show up in an enchanting table, it has be in the minecraft:in_enchanting_table tag

[somber scaffold]

Does MaterialSetTag get initilized by the registries?

I.E if you added something to one of the tags would it then show up in it's respective tag

assuming those two are even the same tags

[upper plover]

MaterialSetTag is gonna get nuked

they aren't real tags and that API to create them isn't good

[somber scaffold]

fair enough

[upper plover]

they aren't ever added to any registry

once ItemType replaces Material, I think we're just not going to update those

[somber scaffold]

So it's just bunch of manually compiled lists then?

[upper plover]

yeah that's what they are currently

[somber scaffold]

glad I didnt make that

lol

[upper plover]

Ok, tag lifecycle events are in. So you should be able to add enchants to enchanting tables, treasure, trades with the API now

[sacred saddle]

Thank you!

[somber scaffold]

goated

[upper plover]

so @rare canopy @old bane @bright owl what is better for having to include a Holder<SoundEvent> in a RegistryEntry builder type?
As far as I see it, we have 2 options. For the fluent getter we can return an Either<TypedKey<Sound>, SoundEventRegistryEntry> or some new type that would essentially be an "either" just with 2 separate sub interfaces, RegistryValue<Sound, SoundEventRegistryEntry> with RegistryValue.Direct<Sound, SoundEventRegistryEntry> and RegistryValue.Reference<Sound, SoundEventRegistryEntry> as the 2 possible subtypes. Personally, I think the either is nicer because once you have it as left or right, you only have 1 generic type

this would be for the JukeboxSongRegistryEntry with includes a Holder<SoundEvent> which can be a key or a direct

[bright owl]

Isn’t the reason why jukebox is weird like that tho just cause of item loading jank reasons

[upper plover]

this has absolutely nothing to do with that, that is an EitherHolder for JukeboxSong itself

[bright owl]

Ah okay, I thought that is what it was pointing to (since jukebox song)

[upper plover]

I could ask the same question about Instrument which also has a Holder<SoundEvent>

[bright owl]

Ahh wait so, this is just creating those types with sound events that are either direct or referenced from the registry right

[upper plover]

yeah, both JukeboxSong and Instrument need Holder<SoundEvent> which can be a key (TypedKey<Sound>) or a direct (SoundEventRegistryEntry)

[bright owl]

Ahhh okay, yeah wow I was confused at first, hmm, so I’m guessing sr need those generics since the entry type and sound are different types right?

[upper plover]

yes, We need 2 generics. Sound cannot be used for direct for a couple reasons. Sound cannot be classloaded yet and Sound doesn't have all the data on SoundEvent. Its missing methods. Besides, for the setter, we will want it to take a Consumer<SoundEventRegistryEntry$Builder>

the fluent setter on the builder is easy, we can just have 2 separate methods that overwrite each other, one that takes that consumer, one that takes a TypedKey<Sound>

[rare canopy]

Making an extra interface that extends either to give better names than “left” and “right” would be nice, or not using either at all and just that

So it’s basically still an either, just (additionally) with better names and generics “hidden” via the interface

But uh I don’t get the part in your message after “or some new type that would essentially be an either”

Here’s an example of what I mean, whether it extends Either or not https://github.com/ViaVersion/ViaVersion/blob/master/api/src/main/java/com/viaversion/viaversion/api/minecraft/HolderSet.java

I used a proper Either for it before, but it’s so much nicer to read and write without it being so stupidly generic. Obv needs a little more code on our side, but user experience is king

[upper plover]

But we need the 2 generics

I cannot see a way around all the types having 2 generics

Imagine your example, but with 2 generics on HolderSet, and the 2 sub interfaces

[rare canopy]

I'm not deep enough into the whole API there I think, I need examples/can only give comments at the end

[upper plover]

https://github.com/PaperMC/Paper/pull/11805/files#diff-806c67f8d37d5fadd51ad314002172c70d3eff1ce45f2fe2c7219f27b9ad9b07R23
https://github.com/PaperMC/Paper/pull/11805/files#diff-b612de9d682e623a6e68550cd774395487c7e53e043685a8aa1c2befc7c2582dR46-R50

[rare canopy]

I still don't follow

why can't you return a new SoundHolder interface that has has/getKey and has/getSound or something instead of the Either

[upper plover]

Because this thing should apply to all types where we have this problem

We wanna make a separate interface for all the types this applies to, will apply to?

[rare canopy]

I agree with you that Either is better than the other alternative you suggested, but imo it's nicer for the API to avoid stuff like Pair/Either, so this is the extra step on top of Either. buut yeah the disadvantage of that is that you need an extra interface for them all with those 4 methods (or just two if you use Optional, but that has the disadvantage of using Optional)

[upper plover]

I agree that it's nicer to avoid it, I just don't see how in this situation

we aren't using it in the setter, we just have 2 setters one for each of the sides of the either

[rare canopy]

so if you don't need the Either type specifically anywhere else and it's just the getter, you just return the extra SoundOrKey/SoundHolder/Whatever

Either is probably fine if you don't like that, it's just one getter in that sort of registry types

[upper plover]

SoundEvent is the only thing it applies to atm, but that is surely to change in the future, I just think a solution agnostic of SoundEvent/Sound is better

[rare canopy]

Isn't there already a bunch more?

like around the whole trim data

but yeah if you want to keep it generic, then I prefer Either

just maybe with nullable left/right instead of Optional, I don't see many people doing more than isPresent and get or ifPresent, but here too it's a more personal preference

[upper plover]

Yea, inlineable, but not itself part of another registry item.

That’s what is unique about SoundEvent. It’s a registry, but it’s also part of another registry (Instrument and JukeboxSong)

We don’t have to worry about creating inlined trim stuff during the bootstrap phase

Cause those only exist on itemstacks

[rugged magnet]

Really cool stuff ! I tried the ENCHANTMENT registry event similarly to the tutorial and it's very nice ! Will others like SoundEvent be exposed soon or is it on pause for now 👀 ?

[rare canopy]

Sounds aren't a modifiable registry (yet)

but you can generally always send sounds via custom keys + resource packs and your own range through API

[rugged magnet]

Indeed but I was thinking of a way to add a Custom music discs. So I guess for now it's not possible (or need hacky ways) to behave properly with a Jukebox

[sacred current]

The issue is is that it's not a network sync'd registry, so, modifying it on the server would put you into a fun desync between the server and the client registry which would break the ability to send that sound event without hacks

[rugged magnet]

hmmm okok I see, thank you

[fresh crescent]

Yeah, now if you want to make a music disc that plays something for a radius of 50 blocks with your custom sound, you'll need nms to create a new SoundEvent object and use nms registry to wrap it into direct holders (reference holders are for events from registry, which have keys, but direct are that don't have a key in registry that will give this object). It's not hacky like custom entities etc, but sadly not part of the API

[rugged magnet]

I tried this but for some reason the jukebox won't play anything and I can't figure out where I messed that up

[fresh crescent]

You can send the code with that in #paper-dev for help finding what may be wrong. NMS is less supported but still some people may be able to help you

[reef flax]

Would it be possible (is it currently possible) to use this registry api to modify the default damage a particular item does (and it will apply automatically to all newly made items)?

[keen kelp]

Nope, Minecraft doesn't sync that so there is no way to change the defaults. In theory the API could let you "change" the defaults by just putting a component in the patch on every ItemStack automatically but that would be confusing

[bright owl]

I’d say thus would prolly be possible when items become data driven, but atm, no.

(If you have a fork tho, just build some logic to add onto the default list and as long as you send it to the client it’ll be good)

[keen kelp]

For Paper to let you change the defaults right now it would either have to inject components into the patch at a packet level which would break creative mode or add code to everywhere a new ItemStack is made to actually add components to the patch which would then be confusing in the API as those would actually show up when plugins queried it

(either one would also be a massive PITA to maintain as it would be a large diff and easy to miss spots where it was needed)

[bright owl]

Yeah no reason for us to get aggressive with such an implementation, esp with data driven items coming soon tn.