Once a player logs in, I have to assign a client entity's inventory so that their held item, worn armor, etc. shows up immediately to the player instead of when their inventory is eventually accessed and assigned by Minecraft's S2FPacketSetSlot packet. The player can place any item or block in this inventory, so the entity is basically a moving chest. The player can also change out their weapon, armor, etc. which will be displayed for all clients.

 

Since item IDs are a thing of the past, this has been broken. My method before was to tell the client about the inventory items on login by sending a string for each occupied slot:

[slot ID]:[item ID]:[stack size]:[stack damage]

Where a damaged iron chestplate in slot 6, for example, would have the values:

6:307:1:40

The client would parse this information and add the item to the inventory for displaying purposes.

 

Now, I've tried identifying the item by replacing the item ID with the item's unlocalized name. I strip off the "item." and ".name," leaving the base item name.

 

Turning the string I send into:

[slot ID]:[item name]:[stack size]:[stack damage]

Which, for the same iron chestplate, would now translate to:

6:chestplateIron:1:40

 

But the iron chestplate in the item registry doesn't have that name. It is called "iron_chestplate". Because of this, I've had to resort to using item IDs anyway.

 

Server-side:

Item.getIdFromItem(stack.getItem())

Client-side:

Item.getItemById(itemId)

 

And it works. To my understanding, this could be a problem with mod items if the server or connected clients do not share the same underlying item IDs, right? Unless there's some other unique identifier for an item that can be sent across the network (i.e. its "name" that is added to the item registry), this is my only option. There doesn't seem to be a reliable way to get an item via its name constant from the item registry since the name constant on that item doesn't seem to be remembered in the item itself, like the unlocalized name is. Granted, some name constants do match the item's base unlocalized name, but most do not. Ensuring that they do would provide a solution to this problem.

We do not control how people name things and there is no enforcement that there registry names are there unlocalized names. Considering items can have many localized names.

However, what I would suggest you do is Use the ItemStack's read/write NBT functions to serialize.

ID's still exist yes, but modders and end users should never see or use them.

Let MC's and FML's internal mechanics handle everything for you.

When a client connects to a FML server, it downloads a list of name -> id mappings so that it's synced up.

But ya, you should use NBT data and use ItemStacks's serialization methods.

Hey, thanks for the fast reply. I'll definitely be looking into that.

 

By "items can have many localized names", did you mean unlocalized? Which item does this? If you meant localized, then wouldn't it be simpler to enforce unlocalized names as registry names since they do not change? While I can't think of any benefit to this right now (except in my situation), it might be helpful for something we're not thinking of at the moment.

I meant many unlocalized names:

    public String getUnlocalizedName(ItemStack par1ItemStack)
    {
        return super.getUnlocalizedName() + "." + ItemDye.dyeColorNames[blockColored.getBlockFromDye(par1ItemStack.getItemDamage())];
    }

Taken from wool

That would screw up the registry.

The registry is fine as is we do not need to enforce anything beyond the requirement to use your mod id.

Also, RegistryNamespaced.getNameForObject exists... you could try that....