#ItemStack DataComponent API

1 messages · Page 2 of 1

past wagon
#

there is no benefit to making them implement Predicate

#

they are testing multiple things sometimes

#

the Predicate interface requires you pass 1 parameter, can't do multiple

viscid burrow
#

^^

wicked fog
late quiver
#

iirc it can be conditional on world, location, and crap too

#

So it can't just take an ItemStack as input, it has to take the Player too

wicked fog
#

the API can only add BlockTypes in builder tho

viscid burrow
#

well, yea, parts of this API are still missing stuff from the looks of it

wicked fog
#

hmm

late quiver
#

Oh, wouldn't this take a Block then?

wicked fog
#

looks like it

viscid burrow
#

things like the item adventure thing takes a object which contains a bunch of stored block info

late quiver
#

If it can only work with blocks (I guess I was thinking of enchantments) then it should be taking a Block and returning true/false

viscid burrow
#

public boolean test(BlockInWorld cachedPos)

#

but, these aren't predicates internally, we can't assume that mojang isn't going to start toying around with the required inputs to test

#

public BlockInWorld(LevelReader world, BlockPos pos, boolean forceLoad) {

past wagon
#

thinking about a mega interface with methods for everything in addition to the data component types...

Aren't we just gonna have almost the exact same problems ItemMeta has now?

#

we can create methods that are all correct with has things, but what happens when a data component requires 2 things to be set at once with no sensible "default" if someone only sets one in the new "ItemMeta" interface?

#

I think mostly the data components will be stable after a bit

#

certainly the more common ones will be, custom name, lore, etc. those aren't changing

paper fern
#

I don't think we need a has for a lot of those. A super interface like that would want to be terribly far away from thinking in a component system in the first place imo.

#

Very much just a "I wanna eat it and it should give me this saturation"

#

if that needs to set two components, so be it.

past wagon
#

so someone calls "setSaturation". what do we set the other required parts of the food component too?

#

idk if there are other requires on food, but imagine a component where there are, and there isn't a "default". We'd have to document what that default was, and its just weird

#

when stacks were nbt, you could always set each individual thing without everything else, and the game just had to support it. but that's not true anymore. You have to fill out each data component

paper fern
#

Yea but like, that only becomes a problem when there is a new field that didn't exist before right?

#

And that field is then also required for the previous layout to work somehow?

#

But like, even if that isn't the solution, we need something imo

past wagon
#

if we had a mega interface like this, but also had some validation when it was applied to an item like you need to set saturation and nutrition, that would solve my issue

#

and those validations could change each version

late quiver
#

No no, like if you call setSaturation that has to add a minecraft:food component to work but that component also takes a nutrition value and a bunch of optional stuff

#

The optional stuff you can leave but do you just set nutrition to 0?

paper fern
#

Yea

past wagon
#

0 makes sense as a default there, but you can imagine a component with a boolean or smth where the default would have to be completely arbitrarily set by us based on nothing

paper fern
#

I mean the default should just be as close to "do nothing" as possible

past wagon
#

better to require the user of the API to set all the required.

late quiver
#

lodestone_tracker takes a boolean where there isn't a clear default

#

It has a target and whether the component gets removed when the target is broken

paper fern
#

Like, if a user in 1.19.2 sets the compass to a specific location, and now there is a loadstone tracker, then yea, we expect people to not want that additional behaviour

late quiver
#

Oh, but that does actually default to true, huh

paper fern
#

tho it does become ugly the more of those "assumptions" you have to make so

#

yea, not perfect. Idk, we just need to brain storm something to replace ItemMeta.

past wagon
#

you have to set the required things

late quiver
#

I'd rather have it just make something up than make it a transactional thing

paper fern
#

Well, but how would you do that when depending on the version before

past wagon
#

the validations are at runtime, when the meta is applied to the stack

late quiver
#

The way you do a transactional thing is a builder and at that point you're just making a weird component API

paper fern
late quiver
past wagon
#

I guess you can't define it

paper fern
#

Yea, at which point, I'd prefer the compile break that is DataComponent API

past wagon
#

but I don't see any other option. a "break" like that or making assumptions about defaults

paper fern
#

Well I don'T mind making assumptions, the issue is more how to keep the "legacy" assumptions out of the "normal" API workflow

late quiver
#

ItemMeta or similar is going to have to make assumptions

#

The real question is how do you track what assumptions you've made or do you care

past wagon
#

oh here is a perfect one. UseCooldown. Takes a float seconds, Optional<ResourceLocation> cooldownGroup

#

I set the cooldown group, wtf is seconds supposed to be?

#

0 is garbage, no cooldown?

late quiver
#

Like if someone sets the saturation then removes it how do you know if you can remove the component patch? Or do you just not bother?

late quiver
paper fern
#

Yea I mean, this feels like what we'll end up with is some weird translation layer from deprecated/legacy components to new ones

#

Which, I would not mind either

#

just, how to prevent crud from fludding the API

late quiver
#

For the record I'm against the idea of this whole thing, I think you should just use the component API and accept the breakages

past wagon
#

we'd need some way to create instance of DataComponentType that aren't in the registry for that then (in the API)

late quiver
#

Bukkit used to break a lot

paper fern
past wagon
#

well it can, for quite a few of the data components

#

custom name, lore, those aren't changing

paper fern
#

Well, with the plain data component API it cannot

#

it just prays they don't change

late quiver
#

If MC ever becomes entirely data driven there would be no point to Paper API vs Forge

#

I mean, the only point would be events but Forge isn't allergic to events like Fabric is

paper fern
#

the API has 0 power, it just is stable because mojang probably keeps them stable

paper fern
late quiver
#

I mean, with these levels of changes ItemMeta is broken af too

past wagon
#

yeah, I feel like there are just different kinds of breaks

late quiver
#

Like, some things you could do with ItemMeta in 1.20 don't work in 1.21

past wagon
#

the problems with ItemMeta arent compile breaks, but behavior breaks

late quiver
#

Some throw exceptions, some don't compile anymore, some just don't work right

past wagon
#

data component just changes those to compile breaks

paper fern
viscid burrow
#

for how long do we wanna keep digging a grave over obviously broken API design?

paper fern
#

Like yea, you get the occasional shit show that is ItemFlag HIDE ATTRIBUTES

past wagon
#

well it was really all the item flags

paper fern
#

Yea

viscid burrow
#

We still need to move everything up the inheritence tree

#

we still need to add 20 dozen reset methods

#

we still need to figure out if we wanna deal with a means to remove components or just leave that aspect broken af

late quiver
#

Heck a good chunk of ItemMeta API at this point is also just badly designed component API

past wagon
#

those "reset" methods are still tied directly to data components, its generally resetting one of them

#

oh yeah, didn't even think about "removing" stuff

#

that is directly tied to data component type, can't get away from it

late quiver
#

I just accepted that removing stuff would not be possible in an ItemMeta-like API

#

If you want that kind of power use components

paper fern
#

Yea, I mean, if we do end up with something wrapping component, I don't think it needs to cover all cases

viscid burrow
#

The big problem is that no matter what happens in a few years time, I can imagine ItemMeta being a 2nd class citizen

past wagon
#

well maybe it only has to cover a few then... like what if it was just a paired down version, only covering the basic data component types

late quiver
#

The day this PR is merged if someone asks an ItemMeta question I'll tell them to use it instead 😄

paper fern
#

I'd hate to see component API to become the main way people interact with items tbh

viscid burrow
#

I mean, if you're doing the basic things like, just setting lore, etc, IM is fine

paper fern
#

for 90% of developer usecases for custom items/reading damage/whatever a more stable interface can exist and should be used imo

viscid burrow
#

but, how many times has somebody asked to do something in which was a PITA which is now literally a few lines of code with components?

late quiver
#

ItemMeta isn't fine, a replacement or port of it that is a facade on top of components might be

past wagon
#

so what about a stable interface for the single-value data component types?

paper fern
#

Yea like, it'll just end in a Brigadier vs BasicCommand kinda vibes

past wagon
#

the ones we think will generally be single-value into the future?

#

custom name, item name, lore, cmd, damage, max stack size, max damage, etc.

#

enchants + attributes have the show in tooltip stuff, not sure about them

paper fern
#

Yea, single things that, even if they move, we can nicely translate to whatever the fuck itll be in component land

viscid burrow
#

Well, yea, having a new thing on the side with more concreteness would be ideal

#

Like, we do need to flatten IM at some point

paper fern
#

I mean, only issue with item meta is that md will abuse the fuck out of it for any new component xD

viscid burrow
#

but, having a nicer API able to deal with the common basic mutations would be nice for the "bukkit-ism"

#

Well, yea

past wagon
#

md_5 is just adding new xxxComponent types

#

like tool/food. so that isn't even following the idea of ItemMeta

paper fern
#

so like, we end up with three systems. a) ItemMeta, b) our minimal bukkit-vibes stable interace over c) data component

viscid burrow
#

Well, yea, but A would be quasi deprecated

paper fern
#

yea

#

but do we need to pull it up/flatten then typing

viscid burrow
#

Yes

#

it's already broken

past wagon
#

why? if its quasi deprecated, why do we care?

viscid burrow
#

Like, you can have components on items which you literally cannot interact with

past wagon
#

b) will just be one interface

viscid burrow
#

Because deprecated doesn't mean removed

#

The issue here is that moving forwrd the entire archtype of ItemMeta no longer makes sense

agile obsidian
#

I do like having a sort of just single interface, it makes more sense with the current representation.

wicked fog
#

At that point it would be much more effective to tell the users how to handle multiple versions with maven/gradle than thinking about how to make a god interface

#

unless that god interface sums up all common (TBD) patterns users may want

viscid burrow
#

I have kinda wanted to do an article on dealing with multiple versions, but, part of it is the reality that at some point you're basically going to just start writing your own quasi API over API

wicked fog
#

and mark it as unstable because inputs may change over time

#

mfw ascii methods in windows api

wicked fog
#

instead of common patterns

wicked fog
#

well, probably a layer between DB <-> MC Scores maybe useful

#

imagine the whole game becoming react

#

💀

#

time to quickly backpaddle to not going down that waterfall

rocky niche
paper fern
#

The thing is, even if we get to that point where everything in json files, the usecase for a tool that best efforts translates older versions to newer ones is gonna be immense

wicked fog
#

correct

paper fern
#

In a code based system, that is just gonna be what a server API would be then

wicked fog
paper fern
#

A layer that best effort translates

late quiver
#

I guess what we really need is to see what that layer looks like

#

Because if it looks like ItemMeta I'm going to tell everyone to use components

#

Like, literally ItemMeta, I mean if there isn't a major overhaul or replacement of it

paper fern
#

Well the alternative would be to use some form of versioned components?

#

But idk how that would fit nicely into the API without making the DX terrible

late quiver
#

An ItemMeta-like system that just didn't let you do everything and filled in dummy values when there was anything that wasn't dangerous to do sounds fine

#

It'd still have to have breaking changes if/when a component got a new value that didn't have a sane default though

paper fern
#

Yea and we just have to guard it like crazy against feature creep

wicked fog
paper fern
#

Add a Factory provider manager somewhere and we got out solution

rocky niche
#

Idk, looking at this discussion about data component api, how it is meant to be bare bone and not widely used, how can it easily break, how it's mean to be just an ItemMeta alternative until a proper alternative appear etc, it just looks to me not like it's more appropriate for this to just become a library from paper than part of paper api and maintained only until a proper item meta alternative is made

Looked again at the implementation and it doesn't really require modifications from the server, it just basically wraps nms components, so it indeed shouldn't be hard to be moved to a library

late quiver
#

It has to be a part of the API, you can't really do this as a library

#

And any higher level more stable thing would be built on top of this

paper fern
#

Yea how the fuck would we expose a wrapper around a library lol

#

That's like saying, brigadier API should be a third party library but basic command should be in paper API

late quiver
#

I don't agree with the sentiment that you should avoid using this API, btw

#

Then again I think your plugin should only support the latest version of MC

rocky niche
viscid burrow
#

The thing here is that you cannot avoid the fact that the underlying data is components

late quiver
#

Right, any higher level thing is not going to let you do all the things this API does either

viscid burrow
#

Well, not exactly

royal kiln
#

I would rather not point people to NMS for anything slightly more advanced with items for the forseeable future until such an ItemMeta replacements gets made and merged tho

viscid burrow
#

The expectation of exposing brig is that you can use it

#

But, if you want a lot of the nice fancy on the side stuff, a command framework can only add onto brig

#

If mojang changed brigs API, we’re unlikely to protect you against that

wicked fog
viscid burrow
#

No sane api promises that nothing will ever break

royal kiln
#

it is easy, but why have an API then

#

at that point Paper may as well just be a modloader

wicked fog
#

we are back at modding, papermc as a plugin system is dead! :aware:

rocky niche
toxic sun
#

is there really much issue with deprecating old stuff, shimming where you can and not bothering where you can't?

wicked fog
rocky niche
#

because no more breaking because the mappings changes

late quiver
viscid burrow
#

I mean, that is part of the reality is that we’re moving forward to a data driven future

#

If you’re not bound to the plugin ecosystem and are starting from scratch with your own code bases, I can’t say that something paper based is an easy answer

rocky niche
wicked fog
viscid burrow
#

Yes

#

That is a viable option to do

#

The goal is to move forward

toxic sun
#

Yeah, what's wrong with that?

viscid burrow
#

Not consistently fall further and further behind what even data packs can do

wicked fog
#

then that will be the only value in papermc components api that it has deprecation notices for renaming stuff

royal kiln
#

imo one of the biggest strengths of the Bukkit ecosystem is that there is a (too) stable API that is pretty easy to use and has lots of features.
And especially with something as essential as items that should continue to be the case. So I don't really think just pointing people to NMS should be considered here.

I also don't really see the issue with deprecating and removing components when Mojang does so. Plugin devs will need to get used to more frequent updates for some time, with how much Mojang reworks currently. Just removing components that no longer exists seems fine to me

viscid burrow
#

The value is that you’ll have access to it from your plugins

late quiver
wicked fog
viscid burrow
#

If you think that vanilla + data packs is the better option for you, go for it

#

Except internals are even more breaky

wicked fog
#

the problem is that the syntax of commands is trash

late quiver
#

vanilla + data packs is guaranteed to break every MC version 😄

wicked fog
viscid burrow
#

Basically, you can’t have the power exposed in vanilla while ignoring vanilla systems

#

API is able to expose stuff to plugins in a safer environment and able to potentially deal with a bit of the edge

rocky niche
#

The issue with that is if breaking changes happen more often, more plugins would take longer time to update, a lot more, and since most of the servers are small servers runed by kids, lots will just stay on older versions because they will wait months until everyone updates, already lots of server owners, if they can, stay at older versions for as long as they can, creating the same issue as with modpacks stuck on really old versions

Don't forget that plugins also loves supporting lots of different versions, so they will also have to heavily delay updates to be able to make some kind of broken support for them, maybe even drop a heavy drop of reflection on top of this

Renaming stuff isn't that often as component changes right now, since component system is still under lots, often and heavy modifications in every version by Mojang, if those modifications should be reflected in the api, then at this moment it's indeed not different from just nms, maybe other parts of api may be more unsafe in nms, but right now data component api won't be more unsafe than nms

late quiver
#

Understand that you can't have your cake and eat it too

#

ItemMeta is a mess, components are unstable, an ItemMeta-like replacement would be less powerful than components so you still need to use components sometimes

#

There is no best of both worlds here, at least none that anyone has thought up so far

glad wing
#

why do we need to have a new itemmeta-like api? if you only care about item name and lore, keep using itemmeta. if you want anything more complex like making something food, use components.

viscid burrow
#

Because ItemMeta is highly flawed and right now the only solution spigot has is to pretend it isn’t and add shoddy components to ItemMeta and pretending that certain operations still work even if they produce generally undesired outcomes

late quiver
#

I mean, there was a plan to port ItemMeta to run on top of this stuff

#

If there is going to be a new thing I suppose that wouldn't happen

#

But maybe people will decide to just do that port and leave ItemMeta in shambles

#

You can't cover everything components do with ItemMeta but you can cover more of it and better than what ItemMeta does

#

And I don't think anyone wants big breaking changes on ItemMeta

viscid burrow
#

Primary goal for ItemMeta using components was a general decluttering

glad wing
#

at least to me, this seems somewhat similar to color codes in strings vs text components. if you just care about making your text have some nice colors, its not entirely unreasonable to use them (for someone that is unaware of minimessage), but if you want fancy stuff like hovers or click events, you have to use text components

viscid burrow
#

That’s why we want to add a more basic api on the side for this

rocky niche
# late quiver ItemMeta is a mess, components are unstable, an ItemMeta-like replacement would ...

I just say that the api is meant to be a lot more stable, especially since it's really accessible to everyone, but this api at this point is no more than the level of stability of nms, especially since everything this api adds can be made with a library for plugins to optionally add and use, it doesn't have any server modifications
I think if the current ItemMeta was made on top of actual data components and not on top of a patch, that could have been already powerful enough for most use cases, if we also flatten it to just 1 interface and not tens of them, clean it up (like use Boolean instead of boolean where needed), it's already something that is really powerful

viscid burrow
#

Your complaint is that the new api would be unstable

toxic sun
#

yeah like ItemMeta can have some cleaning if it needs, not like there needs to be a third system if the old one can be reworked

viscid burrow
#

And your solution is to make large breakint changes to the existing api

rocky niche
rocky niche
viscid burrow
#

Converting ItemMeta to use components would only clean up stuff, it wouldn’t fix the root issues as such

#

And part of the reality is that, yea, if you want full access to stuff, you’re going to need to be closer to api that changes

#

Part of the hope is that mojang stabilises this stuff over time so that becomes less of a concern

toxic sun
#

stop the library talk very silly components need to be in the api

late quiver
#

btw by this same argument particles and sounds shouldn't be in the API either

#

Those break every release or two and we got Wolv (the guy who started the binary patching to avoid ABI breaks madness) to accept that those are just not stable

viscid burrow
#

The plan is to offer a limited intermediary api that will use this api in order to offer a more stable ItemMeta like api which fixes the issues with ItemMeta and lets you do some common operations with more of the safety of plugins messing with items with less risk

agile obsidian
#

I mean the big thing rn is MC is moving towards data driven items, so they are doing agressive changes. I am sure that we will see it stablize once its finished.

past wagon
#

so another thing... I feel like we should have some way to extract a TileState instance out of a stack. What about some BlockEntityWrapper that has a method getTileState(ItemType/Material) that creates an empty block entity of that type, and loads the custom data into it and returns it

#

and a way to set it back

#

cause that functionality currently is still only doable in itemmeta

eager wedge
#

I feel like mojang is trying to do the rest of the components in the next release with how they're doing these Snapshots

pallid atlas
#

Deprecated shouldn't be used in that way, it should only be used if an alternative is already available

#

Spigot used to do that way too much, they would "deprecate" some of the more internal methods that you needed to use in some cases, and it was not the best way of doing that

agile obsidian
#

(But of course it’s also special, but it’s either something like that or literally just holding the api even longer)

pallid atlas
#

Deprecated shouldn't be used like that either

#

Shouldn't any data component breaking changes just be a compile error anyway?

viscid burrow
#

The problem here is that it’s going to break already as mojang is planning to change it

#

Deprecated comes with 0 promise that an alternative exists, it’s just really nice when it does

bleak cargo
#

is error on deprecation at all a weird thing to do in java or kotlin land

#

it's conventional enough in scala land that a lot of org build system configs fail the build if you use a deprecated method

versed torrent
#

it's a weird thing in the minecraft plugin scene in general because people simply don't care about deprecations given that half of bukkit is deprecated but still existent

#

-Werror does exist, however

#

but you can't just get everyone to use that

wicked fog
wicked fog
bleak cargo
bleak cargo
flint sundial
toxic sun
#

This isn't really something you can agree or disagree with, the API docs for deprecated specifically cover this case

#

A program element annotated @Deprecated is one that programmers are discouraged from using. An element may be deprecated for any of several reasons, for example, its usage is likely to lead to errors; it may be changed incompatibly or removed in a future version; it has been superseded by a newer, usually preferable alternative; or it is obsolete.
...
The documentation should also suggest and link to a recommended replacement API, if applicable.

#

There flat out does not need to be an alternative available

flint sundial
#

Would it be so surprising if I said I also disagreed with that? :P

bleak cargo
#

deprecates your API without replacement

versed torrent
#

you can disagree all you want, but deprecation can exist without replacement api regardless of that

toxic sun
#

If you have further disagreements you'd need to take them up with the Java lang mailing list

late quiver
#

This is a silly argument anyway, the thing we're talking about cannot have a replacement until 1.21.2

#

So the options are to leave it in without deprecation and just suddenly remove it in 1.21.2, leave it in but deprecated so people can play with it but know it'll go away soon, or just not have it available at all

#

Pick your poison, you don't get a fourth option

wicked fog
#

Deprecated for removal it is then

late quiver
#

Hey I think the change from fire_resistant to damage_resistant can actually be handled sanely

#

The fire_resistant component can be deprecated for removal but still exist in 1.21.2 and just apply damage_resistant with the fire type under the hood

agile obsidian
#

Yeah that is nice because its literally just a component replacement

sinful oyster
#

Is this supposed to get merged before 1.21.2? Because given all the changes to components in that version, maybe just don't deal with all this deprecation mess and just wait for 1.21.2?

late quiver
#

The goal was to merge it like 2 weeks ago

#

Everyone was happy with the code but then started arguing about upcoming 1.21.2 changes and API design philosophy right before the merge button was clicked

wicked fog
sinful oyster
#

Yeah, but with all those changes coming, does it have to be merged? Waiting seems simpler.

late quiver
#

The first snapshot after 1.21.2 will have more component changes and we'll start this all over again

wicked fog
#

I mean, you should've just merged with ApiStatus.Experimental everywhere

versed torrent
#

the api is gonna be merged so it can be tested more broadly, not because it's stable

#

but then again, if components change, no stable components api is gonna save you

toxic sun
#

why dont we just wait until they finish minecraft

versed torrent
#

the api design itself is a separate thing from the availalbe components themselves

paper fern
#

I mean, maybe machine and I can give it a final read through this weekend (if my current hamster face has decreased enough by then Toothless )

agile obsidian
#

If you guys have anything tho lynx feel free to ping me, I will try my best to respond. 😔

sinful oyster
paper fern
#

I won't have time to read it over until the weekend, das for sure but yea, we will ping you for any change we make

agile obsidian
#

I mean ngl there will be changes each update most likely

paper fern
#

or just make the common executive lynxmaker decision

agile obsidian
#

TRUE

#

or just if any questions

paper fern
#

I am sure you have graced us with deep, precise and generally immaculate javadocs describing every concept

agile obsidian
#

hehe

#

I think alot of the docs dont exist, actually. scream

versed torrent
paper fern
versed torrent
#

the API data is by nature unstable

paper fern
#

Yea I mean, it'll have the same API contract as the registry modification API

versed torrent
#

but the ultimate goal of merging this as experimental api is to get feedback on the api usage itself

sinful oyster
#

Sure, if the main goal is to get feedback by all means, go ahead and merge it. I was just bringing up an idea because of all those deprecation talks. But yeah, I get it, those will probably happen for many more updates after this.

toxic sun
#

There'll be deprecations as well even if we wait until .2 to release it basically

paper fern
#

I mean, the API isn't gonna have many deprecations mostly because it can't "deprecate" things

#

its just gonna not be backwards compatible

#

I guess we could scout snapshots and deprecate early but like

versed torrent
#

the deprecations aren't gonna be on the api but the data, which is different

#

I'd argue that Obsolete is more appropriate

royal kiln
#

is there some way in the API to check if a Component is still valid for the current version? or does it just throw?

versed torrent
#

@LiterallyDoesntEvenWork

paper fern
#

I mean, idk if a compile break isn't better for that

versed torrent
#

if you mean just removing things, possibly, which would also fail at runtime

#

arguably good?

royal kiln
#

would be nice if a plugin could handle that gracefully. e.g. lets say the custom_name component gets removed at some point, it can then check if that exists and fall back to display_name if it doesn't

#

so some "is this component valid on the version I am running on" method would be nice

paper fern
#

ServerVersion stonks

royal kiln
#

yeah I guess you can keep your own mapping of that stuff

paper fern
#

like idk, the API, same as with registry API, is just mojang code lifted into paper-api (well, the data is)

royal kiln
#

so all the API components are gonna be instantly removed in each Minecraft update?

paper fern
#

Given the previous talks in here, there seems to be little to no interest at any attempt to make such specific API remotely adhere to a deprecation cycle

#

I don't see what the point of keeping them around is?

#

beyond the single helper method you mentioned

royal kiln
#

yeah that works too. I was more concerned about them staying in and either not doing anything anymore, or throwing exceptions

paper fern
#

but even that one sounds rather useless, the name might be the same, the format might change

royal kiln
#

thats gonna be super annoying for multiple version support too, glad I don't do that kek

agile obsidian
#

Like item name and display name have different behavior (No italics for example)

paper fern
#

Well yea, same with registry API data. Its just NMS but nicer to access

#

ItemMeta is gonna stay the normal way to do things, until we hardfork and work on a slim wrapper interface that is decoupled from components

versed torrent
#

nms api stonks

paper fern
#

then that is gonna be the normal way to do things, but if you wanna do some crazy specific stuff, here you go, "unstable" API

royal kiln
#

not really a great situation, but yeah I don't think theres any better way

paper fern
#

I mean, the API is gonna be useless for 99% of developers

versed torrent
#

it's just as unstable as using nms directly but it's exposed in api, that's.. really all there is to it, you still need to ensure that X is applicable in Y version when things change

paper fern
#

Well the methods outside the data at least won't suffer from random renames

versed torrent
#

yeah

#

unless owen happens

paper fern
#

fucking owen man Sadge

agile obsidian
#

@past wagon do you think some kind of item predicate api should be added or should lock code component be hidden for now?

past wagon
#

we can't fully represent ItemPredicate unless we add A TON of API

#

ItemSubPredicate is the issue

agile obsidian
#

Lovely hmmm

#

Is it okay maybe to expose some kind of predicate interface then even if you truly can’t make one? Idk kinda sucks

wicked fog
paper fern
#

Like, just an interface for some paper type that is implemented by something the server knows how to map

#

and then a builder to construct that something

wicked fog
#

Unfortunately, as discussed above, Predicate<T> won't be able to be implemented

#

😔

agile obsidian
#

I mean it would be implemented differently

pallid timber
#

I've been considering what to do about these components, and something from Sponge is the notion of a DataManipulator or basically a component, formed of multiple Keys for different "datas". That way it can be represented that a DataManipulator has X Keys, while the breakage is limited to when the underlying data of how something works (like Locks changed this last snapshot) with particular data types, you encourage developers to focus on keyed data over their components altogether.

rain thistle
#

What about a 1st party library, that isn't paper?

Part of the problem I have when leaving plugin development and returning for periods, is not knowing what 3rd party libs exist, are maintained, etc.

If people knowingly have a dependency on PaperDataComponents V1.21, they kinda know what they are getting into vs a dependency on plain paper.

paper fern
#

imo there is 0 gain in not having a thin wrapper around components in paper-api.
Components need to live in paper-api as they are implemented by paper-server. Anything wrapping that we could move out, but yea. Thin wrapper should be somewhere in the api directly as most people should be using that over components lol

past wagon
#

I think we talked about having a wrapper that dealt with the most common of things to change

#

so the wrapper would have custom_name, item_name, damage, durability, custom model data, enchantments, stored enchants, attributes

wicked fog
#

item flags

viscid burrow
#

there is no such thing as item flags

flint sundial
#

Will this API be merged in with 1.21.2? Or is it more of a 1.22 thing?

paper fern
#

We will see ™️

wicked dock
#

paper devs: "omg finally item component api is starting to look great!!"
mojang: "let me drop a big update"

agile obsidian
#

So if yall want to provide feedback

#

🥰🥰

royal kiln
#

I did a bunch of tests yesterday, its really much better. But even with 1.21.2, Moonrise still is a noticeable improvement

night solstice
paper fern
#

it isn't published anywhere no

night solstice
#

guess ill have to use le maven local again and see
is it rebased to 1.21.3 yet or still on .1?

paper fern
#

iirc owen rebased to .3

night solstice
#

thanks, ill take another gander at it then

night solstice
#

so seeing that CMD is still a wrapper not a primitive int
is that still a concern after item-model got added?
i suppose they could still add it as an override though sounds fairly pointless pepothink

otherwise so far was able to use all the new 1.21.3 stuff just fine like before

night solstice
#

might be missin something but lockcode seems missing

image.png
#

and if i want an item to resist say fire and cactus would i need to make my own tag in a datapack containing both?
since it seems to only accept one here

image.png
paper fern
rose plinth
#

lockCode is more difficult to implement now

night solstice
#

and repairable doesnt allow for defining an itemstack in any way? essentially just the material?
so cant make custom armor only repair via a custom item

versed torrent
#

that's how the vanilla DataComponent is defined

night solstice
#

gotcha well better than nothing i suppose, can probably do the rest decently well in a plugin

vivid atlas
#

is it possible to use "illegal" values in vanilla? for example the maximum max stack size is 99 irc, could this be increased beyond that using packets?

past wagon
#

No.

#

Vanilla clients will crash/disconnect if they get an invalid stack

vivid atlas
#

oh thats unfortunate

glad wing
past wagon
#

yeah. There's a lot to be gained by the more structured format that itemstack data has now

ripe goblet
#

wow! The possibilities with this API will completely transform the way custom items are created. I love the design, and I'm really excited to see how custom_data will be implemented. Great job!

patent swallow
ripe goblet
patent swallow
#

maybe it's just to implement pdc for this api? ¯_(ツ)_/¯

#

that's my best guess

bright stump
#

Because it's a component we need to implement

#

But it will have the same functionality

night solstice
#

well guess mojang really changed CMD 💀

terse quest
#

List of floats, booleans, strings, and colors ._. what the heck?

#

Here I was thinking they would have changed it to a namespaced key

wicked fog
#

Colors are a list of floats or an int

versed torrent
night solstice
#

so are these magic values in cmd meant to be like color, broken and all those? replacing overrides?
so a model contains the overrides and CMD isnt an integer but say has "brroken" or what?

terse quest
wicked fog
#

I find it strange that CMD has now a list of stuff and those properties are access by an index and not an id instead

#

it means that it is order dependent and item_model and custom_model_data are tightly coupled

night solstice
#

seems to be structured like u have no overrides now, but priority model-components?
like u can have a model with a trident and a broken comp and which one is first takes priority? idk it is a tad confusin

wicked fog
#

you mean the composed model one?

bleak cargo
#

ngl all the new components is making me consider rebasing to fabric for my server

#

it's like . these exist and i can't really not use tools at my disposal but also they're not really at my disposal because this is taking a while to happen

versed torrent
#

I mean, you can just use userdev for that matter

wicked fog
#

what I'm asking myself is... how slower is all of that running? That must you so much GPU/CPU resources

patent swallow
#

everything is generated at the moment of initializing resource pack

#

shouldn't be slower at all

wicked fog
#

like classes/bytecode?

patent swallow
#

I thought you were referring to rendering

wicked fog
#

both

patent swallow
#

since you mentioned gpu/cpu resources

wicked fog
#

because before everything was hardcoded

patent swallow
#

no it wasn't

wicked fog
#

and so aren't indirections or dynamic data but bytecode

patent swallow
#

how would

#

what

wicked fog
#

my knowledge is stemming from 1.8 and 1.12, not 1.13+

patent swallow
#

models have been controlled by resource packs since 1.14.2

#

shouldn't be much difference performance-wise

#

we can just do much more because we get access to way more variables

paper fern
#

beyond that most of these things were already a thing previously

patent swallow
#

with very crazy workarounds, yea

#

also, etho and evbo heads spotted at 4:58

wicked fog
#

(just a quick question, is posting his vids to item components here a problem?)

paper fern
#

no lol

wicked fog
#

I mean, if it would look like ads or something

paper fern
#

ads for who? slicedlime? KEKW

wicked fog
#

ads for the best MC releases YTer kekw

paper fern
#

Yea so its fine 😅

loud stump
#

I probably know the answer, but just to be sure... If I create for example new ItemStack(Material.GOLDEN_CHESTPLATE) and try to get its EquippableComponent, I will not get the correct data for chestplate but rather some default value, right? This will be fixed by this PR, right?

bleak cargo
agile obsidian
#

Because item meta represents patch

bleak cargo
#

nobody ever bothered to document how any of the stuff underlying the gradle stuff works so its like "here's tiny-remapper :)" with 0 further explanation or where u get mappings from or

bleak cargo
loud stump
flint sundial
versed torrent
#

it's like one method call but sure

#

changing your entire infra just because of a missing API that you can use internals for is silly but maybe that's just me idk

agile obsidian
#

But spigots will need to have alot deprecated

little hawk
trim copper
#

Yep

viscid burrow
#

it's them adding the consume component

#

This is just going to be a "we have stuff in our namespace, they have theirs in theirs"

trim copper
#

Just depreciate the whole package at this point kekw

night solstice
#

finally aaaa

viscid burrow
#

I mean, this is them dealing with a case of a component being changed

#

but, I'm guessing that this also means that, once again, ItemMeta has dataloss?

versed torrent
#

highly adaptable system closely aligned with the structure used in vanilla setups

little hawk
#

It's all legacy, thread-unsafe code anyways

wicked fog
#

so true, PETTHEPAPERFORK

glad wing
#

can we deprecate all of net.minecraft trol

half fulcrum
#

nah just the bukkit part
that'll do it

wicked dock
#

we gonna be switching to hytale with this one 🔥

eager ice
#

this just in hytale release expected before 2080?

little hawk
#

Hytale apparently is now a chinese product, so it'll probably be here by 2026

#

That's my predictions. Riot is fast

bright stump
#

Please keep this channel ontopic

vivid atlas
#

whats hytale?

little hawk
ripe lion
#

Are there any plans or has there been any discussion about connecting this and the registry modification api to allow for custom item stack components?

paper fern
#

no

#

the client does not support that

ripe lion
#

ahh shucks, makes sense I suppose, didn’t think about the client side of it hah

glad wing
#

server-side only components would be kinda cool but probably not much more useful than just using PDC

agile obsidian
#

** DataComponent API Released (1.21.3)**

Api has been merged that allows for items to be interacted with using components that more closely reflect the vanilla implementation. This allows you to easily inherit data from other item types.

// Ooo, this itemstack is a diamond helemet except when worn it looks like a netherrite helmet, and makes a ghast sound when equipped.
ItemStack itemStack = new ItemStack(Material.DIAMOND_HELMET);
                            
Equippable.Builder builder = itemStack.getData(DataComponentTypes.EQUIPPABLE).toBuilder();
builder.model(Material.NETHERITE_HELMET.getDefaultData(DataComponentTypes.EQUIPPABLE).model());
builder.equipSound(Sound.ENTITY_GHAST_HURT.key());

itemStack.setData(DataComponentTypes.EQUIPPABLE, builder);

Additionally suggestions for this API are appreciated, and PRs adding additionally javadocs would be appreciated.

⚠️ NOTE: This api is marked as @Experimental and follows similar api safety as the registry api. This api may change dramatically between Minecraft versions without backwards compatiblity attempts.

little hawk
night solstice
half fulcrum
#

This api may change dramatically between Minecraft versions without backwards compatiblity attempts.
when org.bukkit @Experimental?

ionic copper
#

sweet

late quiver
wicked fog
paper fern
#

?

#

the data stored on there will be upgraded of course

#

the API will just changed to whatever vanilla does

viscid burrow
#

serialisation has nothing to do with this API

#

you'd store your items using the byte APIs as has been recommended for a long while now, and they'll be upgraded using the traditional DFU/DataConvertor path

#

What is being said is that this API will not promise ABI compat, if mojang changes a component, like they did breaking some part of the food component off into Consumable, we will not shield from that with backwards compat

trim copper
royal kiln
#

Time to disable the UnstableApiUsage inspection kek

little hawk
#

Pretty much every API I use is unstable. I think I am doing something wrong giggle

#

Paper Command API,
Paper Registry API,
paper-plugin.yml and co.,
...and now the paper datacomponent API hyperkanna

agile obsidian
#

😰

royal kiln
#

maybe soon we should just say "expect API to break and deal with it, with or without annotation", thats not going to get better lol

paper fern
#

I mean, a lot of the currently experimental API should become stable

#

Like brig and the event parts of registry

viscid burrow
#

the experimental nature is that stuff my change with the API itself

#

the data components themselves are not going to be kept under experimental just because they may change as mojang changes stuff

little hawk
#

Mabye instead of annotating with @Unstable or @Experimental, maybe just make a custom annotation @VersionIncompatible

#

That just annotates that API is stable, but might change across versions

viscid burrow
#

when the API is stable that will be the case

little hawk
#

ah cool

#

I can read minds

toxic sun
#

I'd prefer something similar to how Kotlin handles it, with an annotation per "thing" you're opting into using, so you'd have ExperimentalDataComponents ExperimentalBrigCommands or w/e

wicked fog
half fulcrum
#

isnt it possible to access the data components of an item stack?

paper fern
half fulcrum
#

yeah nvm

#

getData kekw

paper fern
paper fern
patent swallow
wicked dock
#

can you finally negate components from an item?

#

like !minecraft:food

past wagon
#

yes

quasi imp
eager ice
#

I'd imagine so it'd probably be a good idea to

worldly lodge
#

Owen is too lazy to write docs

halcyon fractal
#

Owen is goated for making the api

#

One thing I would want is the ability to copy components form one item to another while having an omit list of components not to copy.
right now I am migrating a lot of meta methods to the new DataComponents. Having not to check for HasItemMeta is such a good thing lol

past wagon
#

yeah, there's def some use to a copy method. especially because it can be implemented to not convert to the API types so its more efficient

#

something like copyDataTo(ItemStack, Predicate<DataComponentType>)
so you can do like

static final Set<DataComponentType> COPY_FOR_MY_THING = Set.of(...);

void method() {
  stack.copyDataTo(newStack, COPY_FOR_MY_THING::contains);
}
#

maybe a merge would be better? idk

agile obsidian
#

Something like that would defo be useful yeah

wicked fog
#

Owen, after the sponge stream, did you look into the link I sent?

#

kinda forgor to ask last time

agile obsidian
wicked fog
#

damn god

#

I thought you were so GOATed that you would develop Sponge and Paper

#

well, the link pointed it to a message here above bedge

viscid burrow
#

instrument type uses upstreams class which doesn't support any of the whole direct reference stuff

paper fern
#

Yes

past wagon
#

yeah, we just need to convert Instrument to wrap Holder

#

@paper fern I want to merge Holderable tmrw, you around?

paper fern
#

Yes

past wagon
#

@agile obsidian did we ever talk about how you can't mess with TileStates with the data component API, but you can with itemmeta? do we care? or just say you should use itemmeta for that

viscid burrow
#

I feel that we wanted to see what mojang was doing with tile states before we went down that avenue?

terse quest
#

Does this API provide us with a way to get components using a string?

#

I suppose you could use ItemFactory#createItemStack but is there a way to only create the components?

past wagon
#

Oh that kind of string. Like the command input format?

terse quest
#

Yeah

past wagon
#

No, nothing specific. Just the existing createItemStack method.

#

That seems sufficient, no?

#

Just create the stack and get the components specifically set on that stack, ignoring the prototype.

terse quest
#

Yeah, I suppose it is sufficient. In my case, since I only need the components specifically such as [minecraft:enchantments={sharpness:1}], I figured I'd ask if there was a way to only create the components.

#

Seems like maybe a possible consideration for the future? If there's a create itemstack, I don't see only the components being too difficult to extract.

agile obsidian
#

🥹👉👈

half fulcrum
#

In regards to #paper-contrib message
Awesome
Just awesome
I can't complain but I have a suggestion (not necessarily component related)
Constructing item stacks is still a bit annoying and introducing a builder pattern would save sooo much code

fathom mantle
#

works nice, just a bit annoyed I can't get a regular profile from a ResolvableProfilen without completing it to get the stored textures, unless I create it myself and copy properties

patent swallow
#

Like it, but there are some components that are missing. iirc entity data component is impossible to set

viscid burrow
#

It's known that w're missing some, most of the ones missing afaik rely on complex data structures we don't really have the means to represent in the API right now, i.e. NBT

patent swallow
#

I'm aware, I'm just voicing the feedback ;)

paper fern
#

The more interesting bit is gonna be people's reaction when it breaks in .5 XD

royal kiln
#

I rather update my plugins with every Minecraft update than dealing with ItemMeta ever again tbh

#

I like the API, its really neat and close to how vanilla handles it.
My only feature request (outside of the missing components) would be exposing DataComponentPatches in the API. Having a bundle of already-set data that you can just apply to any item is very convenient

half fulcrum
oblique dagger
agile obsidian
#

😦

agile obsidian
eager ice
#

I'll put my two cents here as well, with my somewhat limited use of this API, I just can't imagine ever using ItemMeta again, firstly I find the "component" escue style just far better to use, especially over unpredictable casting where sometimes I cast to the wrong Damageable (god damn you 2nd Damageable). Also nice to know that when using this API has no insane magic 🪄 being cast on my ItemStack that I wouldn't expect. Generally ever since this was released I pretty much haven't touched ItemMeta.

#

Probably the second best API in PaperMC right now (MenuType is clearly far better)

royal kiln
#

But to be fair: I don't do public plugins, so I don't care about multi-version support at all

spice trout
#

In general, I like the API! Also for me it has replaced ItemMeta. But if you would like some feedback: 😁

It's a bit tricky to discover. In most of Bukkit, if a method requires a Foo, you can just pass a Foo.WHATEVER. Examples: Material.PAPER, Biome.TAIGA, Wolf.Variant.ASHEN. IDE autocomplete is your friend. But this one requires a Valued, so it requires some memorization and example code to get started.

#

My main complaint is the lack of backwards compatibility. For example, this code in 1.21.4:

    stack.setData(DataComponentTypes.ATTRIBUTE_MODIFIERS, Material.GOLDEN_HELMET
        .getDefaultData(DataComponentTypes.ATTRIBUTE_MODIFIERS)
        .showInTooltip(false));
#

This will likely change into something like this in 1.21.5:

paper fern
#

Yea, backwards compat with this API has never and will never exist

spice trout
#

stack.setData(DataComponentTypes.TOOLTIP_DISPLAY, TooltipDisplay.hiding(DataComponentTypes.ATTRIBUTE_MODIFIERS));

#

But would be great if the old way would still work for another Minecraft release! I know it's annoying and ugly to implement: setData would need to check if showInTooltip was set, and then go and add/modify another component. And I know there will be cases where backwards compat will be too difficult to implement.

#

And yeah, having a lot of helper methods on ItemStack would be nice. My wishlist:

    setMaxStackSize(int)
    setMaxDamage(int)
    setDurability(short) - already exists
    setUnbreakable(bool)
    setItemName(Component)
    setRichItemName(String) - passed through MiniMessage
    setLore(List<? extends ComponentLike>)
    setRichLore(String) - split by \n, passed through MiniMessage
    addEnchantments(Enchantment, int) - already exists
    setEnchantmentGlintOverride(Boolean)

Then I think it's safe to slowly deprecate ItemMeta. 🙂

paper fern
#

We are possibly going to introduce a thin layer on/around ItemStack that does promise backwards compat but only for the most common methods

#

e.g. the stuff you posted above

#

for the nitty gritty BS like showInTooltip, we cannot provide backwards ever without dooming this API for a quick death

spice trout
#

Yeah, was already afraid that a backwards compat layer in setData would be too much to ask. Oh well...

#

But yeah, I like the API a lot. 🙂

paper fern
#

Well, again, as ItemMeta is deprecated, at least I'll look into a thin type that is "set me this, do whatever it takes"

#

it's not gonna have e.g. has methods, either it can compute a return value or not from the itemstack

#

and it will be a lot less detailed than this API

austere sonnet
#

I should change my plugin to use this

flint sundial
flat berry
#

Hi, nice work with the api. Some feedback:

  • I'd like the selected item index of the bundle contents component to be exposed, so that I can predict what will happen on a click.
  • Utility functions like BundleContents#tryInsert, BundleContents#getMaxAmountToAdd (which exists on the nms bundle contents builder) would be nice to have
  • It would be nice if custom model data colors could also be supplied as int[] / IntList
  • The custom model data component doesn't seem to be able to handle alpha values in colors, trying to read the component of an item stack like this: /give @p stone[minecraft:custom_model_data={colors:[-1]}] throws an exception
night solstice
flat berry
#

sure, but if the give command doesn't filter it out I should still be able to read it from a plugin

versed torrent
#

the colors list in the custom_model_data explicitly does not handle alpha

#

it's always 1.0f

#

oh, unless you pass it as an integer rather than a list of floats for r,g,b thonk

#

this looks more like a mojang bug that intentional design

flat berry
#

Doesn't matter, Color#fromRGB forces the upper 8 bits to be zeros

# 
    @NotNull
    public static Color fromRGB(int rgb) throws IllegalArgumentException {
        Preconditions.checkArgument((rgb >> 24) == 0, "Extraneous data in: %s", rgb);
        return fromRGB(rgb >> 16 & BIT_MASK, rgb >> 8 & BIT_MASK, rgb & BIT_MASK);
    }
#

So this item stack can also not be read: /give @p stone[minecraft:custom_model_data={colors:[[1, 1, 1]]}]

versed torrent
#

how can it not?

flat berry
#

What do you mean?

versed torrent
#

"this item stack can also not be read"

#

read where? in what way?

#

ah, i see what you mean

flat berry
#

Get the colors with the data component api. It tries to convert the color (which is stored as an int in the nms component) using org.bukkit.Color#fromRGB. Since it has an alpha of 255, it fails.

versed torrent
#

the precondition

#

yeah that should probably be using fromARGB instead

agile obsidian
#

cc @rose plinth