Add expr to get the show item hover tag for a given item.

[sovdeeth]

Problem

Creating a hover:show_item tag requires the ability to get a string representation of all the necessary components of an item, which is not simple in Skript. See https://docs.papermc.io/adventure/minimessage/format/#hover for details.

Solution

Adds a property expression item hover text of %itemstacks% that automatically produces the tag "<hover:show_item:...>" for those items.

Testing Completed

Added simple regression tests.

Supporting Information

---

Completes: none
Related: none
AI assistance: none

[bluelhf]

Why not an expression that applies the show_item hover action to a Component?

[sovdeeth]

Why not an expression that applies the show_item hover action to a Component?

Because that would be rather difficult to put into a string with %%. Could be a separate expression though.

[bluelhf]

Why not an expression that applies the show_item hover action to a Component?

Because that would be rather difficult to put into a string with %%. Could be a separate expression though.

Makes sense. I was worried about the hackiness of returning a minimessage string back to the user, but that's now solved! This seems like a pretty good way of providing components to the user in general, assuming that interpolating it into a minimessage string works like you'd expect.

[Fusezion]

nvm I'm just dumb and forgot to use formatted, though I still am concerned about the overall size of the string for this

I did eventually get the string to break by adding too much data into it
top portion

bottom portion to show it didn't just end

and proof it does work with smaller items at larger numbers (this one breaks somewhere around 25)

additional notes:
Without proper implementation some oversized items (though purposeful here) do instead just throw an exception into console
where as skbee who uses the more intended design doesn't have this issue (and works)

(Methods ran to cause both)

(Console exception thrown from skript)

(Hover of skbee)

[sovdeeth]

This is because you're forcing it back into a string before reformatting. If you used component addition, this likely would not be an issue.

[Fusezion]

This is because you're forcing it back into a string before reformatting. If you used component addition, this likely would not be an issue.

Sure, but how often do you see people use x + y when they need to quickly append something?
I understand I did it wrong but 90% of the time when I'm looking over any type of help channel I am not going to see x + y
Especially given the fact skript still doesn't allow {_empty} + "myString"

[sovdeeth]

This is because you're forcing it back into a string before reformatting. If you used component addition, this likely would not be an issue.

Sure, but how often do you see people use x + y when they need to quickly append something?
I understand I did it wrong but 90% of the time when I'm looking over any type of help channel I am not going to see x + y
Especially given the fact skript still doesn't allow {_empty} + "myString"

Yeah, my point is that to put it into a string, like you're testing, it has to become a string again, there's no way around that. It would be the same if you attached the component to another like skbee does and then serialized it back into a minimessage string to put in another string. It's just unavoidable with the test you're doing.

Keeping it as a component doesn't have that issue

[APickledWalrus]

A few minor things

[APickledWalrus]

Suggested change

	.addPattern("[a[n]] [show] item hover [text] component (for|using|from) %itemstacks%")
	.addPattern("[a[n]] [show] item hover [text] component[s] (for|using|from) %itemstacks%")

For better plurality support: item hover components for {_a} and {_b}

[APickledWalrus]

Suggested change

	throw new IllegalStateException("toString should be overridden");
	return "item hover component";

I don't think this would ever be called, but contractually it's probably safer to just implement it.

[APickledWalrus]

Suggested change

	}
	}