Improve itemframes

[TheLimeGlass]

Description

Improves Item Frames as Snow always wanted.

Sets the entity data pattern to

item[ ]frame(|1¦s) [(with|of) %-itemtype%] [[with rotation|rotated] %-rotation%]

for more proper support of ItemFrames while also registering ItemFrames as a classinfo for dedicated syntaxes.
Adds org.bukkit.Rotation and a utility effect for easily rotating an expression that returns a rotation and/or itemframes and rotation's self.

Examples:

# Spawning
spawn an item frame with lime stained glass rotated 225 degrees at target block
spawn an item frame of stone rotated 90 degrees in the direction of player from target block:
    rotate event-item frame by 90 degrees
    set item of event-item frame to lime stained glass named "example"

# EffRotate
rotate the event-item frame clockwise 2 times
rotate the event-item frame by 225 degrees

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #414 (non-closing) and #2874

[Absolutionism]

What do we think about making an expression to grab the rotation of an itemframe?
Also, not sure if possible, but combined with that expression, make a test structure within EffSecSpawn.sk spawning item frames with a rotation and ensuring the rotation is correct.

[Fusezion]

T-te-test!

[sovdeeth]

I'm concerned that this rotate effect will add a lot of ambiguity to the existing rotate effect for displays, vectors, and quaternions. I'd like to see the two integrated if possible. I'm also concerned about adding the Rotation class, as I think it will cause confusion with the existing ExprAngle expression.

Can we not treat item frames as any other rotatable object and just snap their alignment to 45 degree angles if the rotation would result in something like 60 degrees?

[sovdeeth]

I'm concerned that this rotate effect will add a lot of ambiguity to the existing rotate effect for displays, vectors, and quaternions. I'd like to see the two integrated if possible. I'm also concerned about adding the Rotation class, as I think it will cause confusion with the existing ExprAngle expression.

Can we not treat item frames as any other rotatable object and just snap their alignment to 45 degree angles if the rotation would result in something like 60 degrees?

reminder to address/respond to these concerns

[TheLimeGlass]

I'm concerned that this rotate effect will add a lot of ambiguity to the existing rotate effect for displays, vectors, and quaternions. I'd like to see the two integrated if possible. I'm also concerned about adding the Rotation class, as I think it will cause confusion with the existing ExprAngle expression.
Can we not treat item frames as any other rotatable object and just snap their alignment to 45 degree angles if the rotation would result in something like 60 degrees?

reminder to address/respond to these concerns

They're different rotation objects

[sovdeeth]

I'm concerned that this rotate effect will add a lot of ambiguity to the existing rotate effect for displays, vectors, and quaternions. I'd like to see the two integrated if possible. I'm also concerned about adding the Rotation class, as I think it will cause confusion with the existing ExprAngle expression.
Can we not treat item frames as any other rotatable object and just snap their alignment to 45 degree angles if the rotation would result in something like 60 degrees?

reminder to address/respond to these concerns

They're different rotation objects

I understand, but the point of my comment is that we shouldn't have two methods of rotating things, one that one works for x and one that only works for y. They should be unified so that all the rotation methods work with everything.

[TheLimeGlass]

I understand, but the point of my comment is that we shouldn't have two methods of rotating things, one that one works for x and one that only works for y. They should be unified so that all the rotation methods work with everything.

Can you provide what you vision to have happen about the input of the rotation in the pattern since they're going to be different objects. They won't parse the same.

[sovdeeth]

I understand, but the point of my comment is that we shouldn't have two methods of rotating things, one that one works for x and one that only works for y. They should be unified so that all the rotation methods work with everything.

Can you provide what you vision to have happen about the input of the rotation in the pattern since they're going to be different objects. They won't parse the same.

rotate {item frame} by %number% degrees which just snaps to the nearest 45 degree mark. Avoids the need for a rotation type that adds confusion about where it can be used (and possibly causes conflict with existing code that uses set {x} to 45 degrees).