Implement a material literal into skript

[Fusezion]

Suggestion

Add a proper material literal into to skript that differs from itemtype.

Why?

There's been countless times in skript api where a material is needed for something but instead skript has to do a
ItemType#getMaterial(), BlockData#getMaterial() and ItemStack#getType() for conversions.

Implementing a proper material type can solve many of those as well as provide users more explicit control.
i.e. command /item <itemtype> would accept stone of sharpness 100 but maybe the developers don't want that

Other

No response

Agreement

• I have read the guidelines above and affirm I am following them with this suggestion.

[sovdeeth]

I don't think the benefits outweigh the costs here. Adding a material type would start to add conflicts/confusion with normal items and would require a lot of work to integrate naturally. For all that effort, the user doesn't really get any benefit other than naturally restricted inputs that don't do anything new, really.

[ShaneBeee]

Im going to give a long winded response here.

Im 50/50 with Fuse on this.

Skript's ItemType is severely flawed, super outdated, and is full of bandaid patches.
It's something that should have been removed back when MC 1.13 came out and work began on Skript 2.3.
Aliases, which are the heart of ItemType, are slowly being phased out, and this class should be too.
The massive amount of data that ItemType/ItemData holds no long makes sense anymore.
Is it a material? is it an ItemStack? is it a BlockData? ... well you’re in luck, its all of those 😂
This also clogs up the variable file with so much unneeded data.

As for Material being added and my 50/50.
ItemType/ItemData so badly needs a replacement, I do feel like Material would be the wrong choice at this stage.
Material is super old Bukkit code that represents both Item/Block types in Minecraft.
Bukkit added ItemType/BlockType a few years ago, and seems like it's the direction both Bukkit/Paper are going to want to go towards.
Paper has stated they do plan on deprecating Material in the future, and moving towards a more registry like API, most likely just going to use ItemType/BlockType.

When this happens, Skript is going to apply even more bandaids to ItemType/ItemData, and make it even harder to work with.

I don't understand why Skript wants to hold onto this legacy class so hard, it's doing no one any favours, it's not very future forward.
The amount of adjustments to ItemType/ItemData over the years has just continued to make these classes messier and messier.

I've brought this up many times over the last few years only to get brushed off by the team, as they keep slapping bandaids on this class, which by this point is just held together by duct tape and Jesus.

tl;dr:
Skript really needs to start focusing on what Bukkit/Paper/Minecraft provides rather than all these made up classes representing multiple types in one.
This is getting more and more evident as Minecraft shifts to moving more things to be data driven (ie: DataPacks).

[sovdeeth]

I agree with you about the current state of ItemType, but I disagree that it needs to be phased out. There are many cases in which Skript would like to be able to represent a 'class' of items, rather than a set of concrete items. This manifests in aliases as any log, for example. It's useful for things like any item tagged as "xyz", or if {_x} is a diamond sword.
The power of ItemType is that it can represent a set of attributes (materials, lores, enchants, components) at once, which allows many more capabilities when working with items.
The alternative is to put more burden on the user, which is also a valid route but I think one of lesser value. However, I don't want to derail this issue too much so further discussion can be had on discord or in a separate issue/discussion.

[cooffeeRequired]

For me, I'm 50/50 as well.
Skript instead of focusing on what realistically Bukkit and Paper does. So it prefers to constantly make pointless patches and the whole code is hard to maintain. Also, the ItemType has no business being in the Script anymore in my opinion. None of this is realistically used and it's more chaos than benefit. Even for developers.

[Fusezion]

Just to clarify some things here as I see it's kind of derailed, I'm not asking for Itemtype to be removed nor am I explicitly asking for the mistake of org.bukkit.Material to be implemented into skript (this would likely cause more legacy loading if not properly handled)

I'm only asking for an explicit type that is only literal materials not skript's internal mistake, of adding extra parser information onto itemtype's parse method.

From my view and from when of %enchantmenttypes% was last talked about when Ayham was around doing the enchantment/item toString update prs it was generally agreed that stone of sharpenss was bad and would of been better as an expression from what I remember.

I just want a new material classinfo that in all honestly could ride off of itemtype but explicitly with no additional parser information. Only for literal types