You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BlockTools.getReadableName() doesn't seem to be seeing custom name data for blocks.
This discovery came about as I was going to make a suggestion about this in RFTools but then I found someone had already made a suggestion for enhancement that I was looking for. McJtyMods/RFTools#1365
Digging a bit through the code to see what it would take to implement something like this, I found that the relevant code is as follows.
mcjty.rftools.blocks.storagemonitor.PacketGetInventoryInfo.toInventoryInfo() is what actually sets the display name, whether [UNLOADED], [REMOVED], or whatever the inventory is named.
It does so by calling BlockTools.getReadableName() which in turn makes an item stack from the block at the given position and then asks that for the display name.
The proper method is being called, getDisplayName, which should in theory be able to return a custom name, but apparently the custom name is being lost when creating the itemstack.
Probably the vanilla chest class doesn't write any nbt data from the tile entity into the itemstack when calling getItem(). The contents of the chest not being there makes sense, but the display name also not being there is unfortunate.
I have no exact suggestion as a lot depends on the intended behavior of getReadableName. If calling it with a world object and a position in that world is supposed to be able to return custom names, then maybe a check should be added to see if there's a tileentity that has a special name for us.
If getReadableName shouldn't be returning any custom names, then maybe there should be a new method added which can see such names, and then a change added in rftools to call the new method.
Or maybe, with this, it will be officially decided that such functionality will not be implemented, and the enhancement over in rftools can be closed.
also because the actual change, if any, would be made here in mcjtylib, I thought it would be best to submit the issue here. if not, please advise.
The text was updated successfully, but these errors were encountered:
I think during itemstack conversion the custom display name NBT tag should be written. This would not hurt anything since it's only one NBT tag that needs special love, and that name could be available for other tools later.
BlockTools.getReadableName() doesn't seem to be seeing custom name data for blocks.
This discovery came about as I was going to make a suggestion about this in RFTools but then I found someone had already made a suggestion for enhancement that I was looking for.
McJtyMods/RFTools#1365
Digging a bit through the code to see what it would take to implement something like this, I found that the relevant code is as follows.
mcjty.rftools.blocks.storagemonitor.PacketGetInventoryInfo.toInventoryInfo() is what actually sets the display name, whether [UNLOADED], [REMOVED], or whatever the inventory is named.
It does so by calling BlockTools.getReadableName() which in turn makes an item stack from the block at the given position and then asks that for the display name.
The proper method is being called, getDisplayName, which should in theory be able to return a custom name, but apparently the custom name is being lost when creating the itemstack.
Probably the vanilla chest class doesn't write any nbt data from the tile entity into the itemstack when calling getItem(). The contents of the chest not being there makes sense, but the display name also not being there is unfortunate.
I have no exact suggestion as a lot depends on the intended behavior of getReadableName. If calling it with a world object and a position in that world is supposed to be able to return custom names, then maybe a check should be added to see if there's a tileentity that has a special name for us.
If getReadableName shouldn't be returning any custom names, then maybe there should be a new method added which can see such names, and then a change added in rftools to call the new method.
Or maybe, with this, it will be officially decided that such functionality will not be implemented, and the enhancement over in rftools can be closed.
also because the actual change, if any, would be made here in mcjtylib, I thought it would be best to submit the issue here. if not, please advise.
The text was updated successfully, but these errors were encountered: