Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create NBT Support with Variant in cItem #5454

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

12xx12
Copy link
Member

@12xx12 12xx12 commented Oct 30, 2022

This PR tries to kick of further development if additional data is stored into an item.

There is a new member m_Properties which is a vector of a variant which stores all possible data.
Access is done with get<>() and set<>() which both are templated methods which return a optional which contains the requested data. I tried to keep access as simple as possible to ensure easy programming. Sadly optional doesn't support references so the value has to be retrieved with get, modified ad written back with. set.

Any use in the C++ code is adapted to this. Old Lua Binding should be intact by manual binding the old values.

Im am not 100% sure about my Lua implementation, please check that!

@tigerw
Copy link
Member

tigerw commented Nov 2, 2022

Looks good, seems like the right idea! My main initial observation is that std::optional isn't very graceful; one liners are expanding into 4+ lines before our very eyes. I don't think there's much we can do about that.

For the tags we're storing in the variant, I remember vanilla putting a lot of fields in the root level but we could group ours by purpose, mainly to prevent any conflicts. It's also surprising that vanilla calls for the item's damage to also be stored in the variant as a "general tag", this will probably cause a bit a breakage and API headaches.

I can have a more detailed look 🔍 later...

@12xx12
Copy link
Member Author

12xx12 commented Nov 2, 2022

Reguarding std::optional

Yeah. This isn't very graceful indeed. I thought about that but returning a Boolean and using a reference as a parameter as the better didn't seem better. And creating the requested value if it didn't exist destroys the purpose of the variant vector.

Reguarding the damage.

Good point. I kept the integer values purposefully out of the variant for easy access and since they consume little memory it shouldn't be that bad.
Since 1.13+ requires us to transmit the item damage in the NBT data to correctly display the damage and the damage is actual damage not some value which might indicate "sub-items" like wood this value might be restricted to only tools/armor/... in future versions. This could be put together with the unbreakable tag I indicated

@12xx12
Copy link
Member Author

12xx12 commented Nov 3, 2022

I need some help with the manual bindings to the firework item. I am not quite sure how to obtain a pointer to the firework item since a pointer is needed

There was no function to push a firework item to the lua stack so the firework pointer is evaluated to bool which is :(
@12xx12 12xx12 mentioned this pull request Nov 5, 2022
9 tasks
broken call to lua usertype and removed removed api entry
@12xx12
Copy link
Member Author

12xx12 commented Mar 20, 2023

Hello CI are you there?

@12xx12 12xx12 requested a review from tigerw March 25, 2023 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants