[SPIGOT-4618] Add ItemTagType to Entites Created: 10/Feb/19 Updated: 20/Jun/19 Resolved: 20/Jun/19 |
|
| Status: | Resolved |
| Project: | Spigot |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Bjarne Koll | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | API, | ||
| Version: | 1.13.2 |
| Guidelines Read: | Yes |
| Description |
|
Well this is pretty much just a suggestion, but would it make sense to adept the CustomItemTagContainer interface onto entities ? The metadata store has its advantages when it comes to storing objects directly, but for something like a marker, a binary approach like the TagContainer may also be helpful.
I just want input prior to putting work into a PR |
| Comments |
| Comment by Yannick Lamprecht [ 20/Jun/19 ] |
|
I think that should be closed. https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/commits/b0d235627535d965e1533c7de0127d05abaee00b |
| Comment by Bjarne Koll [ 21/Feb/19 ] |
|
I mean if I find time to write wrapper code for the old class names to provide deprecated use case I would profere that. I am personally happy with the design of the API , but the name was a mistake on my end so I'll probably open/update another ticket about my progress once the first 1.14 API has been announced |
| Comment by md_5 [ 21/Feb/19 ] |
|
If the ONLY change is the class/package names, then I guess we could do a remap for 1.14. Not ideal though. |
| Comment by Bjarne Koll [ 21/Feb/19 ] |
|
Sounds a bit of to do zombie.getCustomTagContainer().setCustomTag(key, ItemTagType.STRING, "whatever"); doesn't it ? |
| Comment by md_5 [ 21/Feb/19 ] |
|
Just leave the name as is? |
| Comment by Bjarne Koll [ 14/Feb/19 ] |
|
After spending some time looking into it, the system itself works great but the name is the only damn problem. I don#t think it makes sense to hack our way around it. We can either wait for a "game-breaking" update. 1.14 maybe ? To redo that API part. Question is if such "backwards-compatibility" breaking change is allowed in 1.14. Or we leave it as is and people will need to use Metadata |
| Comment by Bjarne Koll [ 10/Feb/19 ] |
|
Alright. Gladly static fields are inherited. So we can rebase the ItemTag system on a more generic one and write a workaround for the item one to still work. I'll mark them as deprecated once I got a fully fledged tag system up and running |
| Comment by md_5 [ 10/Feb/19 ] |
|
It's probably too late to make breaking changes, so yes it has to be backwards compatible. |
| Comment by Bjarne Koll [ 10/Feb/19 ] |
|
The question is, how disruptive this change will be and I am not sure about how backwards compatible such change has to be, as it was released a month ago |