These procedure blocks allow one to store items without requiring a GUI, which partially decouples custom GUIs from inventories.

The correct approach for storing items is using a container. I think to decouple this, it would make more sense to have containers of items/entities/blocks an independent checkbox from GUI selection.

Are there vanilla cases where item stacks are stored like this, just so we don't do something that shouldn't be done?

The correct approach for storing items is using a container. I think to decouple this, it would make more sense to have containers of items/entities/blocks an independent checkbox from GUI selection.

While this wasn't the intention of this PR, these procedure blocks can be used for that purpose, which is why I mentioned it.

Are there vanilla cases where item stacks are stored like this, just so we don't do something that shouldn't be done?

Yes, they do, but via container. I was asking if any of those directly store item stacks to and from their data bypassing the container system?

If e.g. item has items in it, one should access them via inventory procedures, not via NBT procedure blocks

Yes, they do, but via container. I was asking if any of those directly store item stacks to and from their data bypassing the container system?

I don't think so, no. But containers are just helpers that save to tags in the end.

I'm not arguing that this is the cleanest approach one could take to manage inventories, but it is one of the possible uses of these procedure blocks.

But containers are just helpers that save to tags in the end.

Correct. But they are the official interface to acces this storage, not direct NBT management.

I am wondering if it is wise to allow users to directly access and store item like this, because this will reduce mod intercompatibility. I feel this PR is adding something similar to the wait block, which should never exist in the core because it allows users to do things they shouldn't (and brings bad name to MCreator mods).

What would be legitimate use of those procedure blocks that does not in some way or another do something that inventory/container/capability should do instead?

What would be legitimate use of those procedure blocks that does not in some way or another do something that inventory/container/capability should do instead?

Storing items in vanilla entities/blocks/items that do not have inventories would be one of the biggest advantages. Say you want to have a zombie be able to pick up more than just armor and mainhand/offhand items, you could do it with these procedure blocks to create a player corpse mechanic.

Plus we currently have users using player variables for creating GUIs for accessories/additional player inventories which create additional network traffic when player variables are synced, NBT tags would reduce the load on that too.

Storing items in vanilla entities/blocks/items that do not have inventories would be one of the biggest advantages.

I mean, technically speaking, we would need to attach capability for this.

Plus we currently have users using player variables for creating GUIs for accessories/additional player inventories which create additional network traffic when player variables are synced, NBT tags would reduce the load on that too.

Player NBT is not synced, so this would not help that much and could make players think they made something that works but will not on dedicated servers / LAN.

At minimum if we add this feature to the core, there should be new warning added to all of those blocks that inventory should be used whenever possible to discourage at least the users that read warnings.

Player NBT is not synced, so this would not help that much and could make players think they made something that works but will not on dedicated servers / LAN.

Player variables are not synced if they are set from the client either, so there is no difference in this use case. When I reference a reduction in network traffic, I mean that they will not be sent to the client every time they are updated.

Player variables are not synced if they are set from the client either, so there is no difference in this use case.

NBT is not synced from server to client, there was so much confusion around this that we had to add procedure warnings that users happily ignore and then wonder why certain things don't work

As I said, at minimum those blocks should emit very clear warning on when not to use them (and to avoid using them in general)

As I said, at minimum those blocks should emit very clear warning on when not to use them (and to avoid using them in general)

Added in the latest commit