pattern providers are not keeping name after renaming in anvil

[DoomSquirter]

Describe the bug

I renamed 8 pattern providers the same name in an anvil like I've always done in older versions of ae

Placed them down, and they show up in pattern access terminal w/o name

How to reproduce the bug

rename pattern providers in anvil and check access terminal

Expected behavior

for the pattern providers to keep the old interface behavior after being renamed in an anvil obviously if you place and then break the provider, it loses it name like it always has but the name should be there when you place it

Additional details

appliedenergistics2-19.0.8-alpha playing enigmatica 10

Which minecraft version are you using?

1.21

On which mod loaders does it happen?

NeoForge

Crash log

sorry I'm not crashing the game for something this simple

[DoomSquirter]

ok, added information

I checked the nbtdata of the placed block it has retained the name I gave it in the anvil

so possibly the problem rests solely in the access terminal not showing it https://cdn.discordapp.com/attachments/1252714362297127062/1264186240194969640/image.png?ex=669cf4af&is=669ba32f&hm=ac0957b74ab29cf583e6cae0f6969af1f7cf17fa7ed90e527ec74219405bdfc9&

[Mithi83]

After a bit of testing and looking at the code: Naming is done on the machine side of things, not the pattern provider side. What works is naming an interface (the part variant, not the block variant, which is kind of weird that this works differently) and place it on an pattern provider. Smells like its not the way it should be

[62832]

It's admittedly not intuitive, but that is the way it should be. Entries listed under the Pattern Access Terminal are always grouped by the sort of machine the pattern providers are up against and not the providers themselves.

If you're saying, however, that naming a block interface doesn't work and naming the part does, then that is a bug.

[shartte]

We might wanna change it, I suppose 🤔 But it makes grouping harder.

[Mithi83]

I‘ll doublecheck the block interface tomorrow, but I‘m pretty sure it was not the same as the part variant of the interface.

[DoomSquirter]

so are you saying I need to stop renaming the pattern providers and instead rename the molecular assemblers that are against the pattern providers instead?

Again, it's keeping the name correctly in the nbt. I'm just verifying that moving forward, this is the new way to do it?

edit: verified the moleculars keep their name as shown by looking at the nbt but the access terminal still doesn't show the name

[Mithi83]

I said nothing about Molecular Assemblers, just about Interfaces, more specifically about Interfaces in the part variant (i.e. the flat version, not the full block version). Molecular Assemblers might fall into the same category as interfaces in their block variant and as 62832 said this might be a bug. This is what I meant earlier by smells like it’s not the way it should be.

Changing the behavior towards naming Pattern Providers rather than the attached machines is a design choice that would have to be carefully considered. There might be edge cases which make that impractical (e.g. multiple differently named blocks attached to the same pattern provider). Also looking at the default behavior of taking the name (e.g. „Molecular Assembler“, „Furnace“) of the attached block it would be logical to rename the attached block to change that name.

I‘ll investigate further.

[Mithi83]

Simple setup, from left to right: Creative Energy Cell, Smart Cable with Pattern Access Terminal, Pattern Provider (without any name) and next to it different machines as follows yields a group name as follows:

1. nothing attached -> ME Pattern Provider
2. ME Interface as a full block (unnamed) -> ME Pattern Provider
3. ME Interface as a full block (named TEST) -> ME Pattern Provider
4. Molecular Assembler (unnamed) -> Molecular Assembler
5. Molecular Assembler (named TEST) -> Molecular Assembler
6. ME Interface as a part (unnamed) -> ME Interface (icon is of the ME Interface part)
7. ME Interface as a part (named TEST) -> TEST (icon is of the ME Interface part)
8. ME Interface as a part (named TEST) and ME Interface as a full block -> TEST (icon is of the ME Interface part)
9. ME Interface as a part (named TEST) and Inscriber (named TEST)-> ME Pattern Provider (tooltip says: "Adjacent to Different Machines\nTEST\nInscriber")

So my conclusions are as follows:

1. A ME Interface in full block mode is not detected at all as a valid machine for the Pattern Provider. This is inconsistent with the part variant and therefore a bug.
2. Renamed Molecular Assemblers and Inscribers are not displayed with the new names. This is unintuitive and from a user's point of view hard to understand. Whether it's an actual bug remains to be seen.

[Mithi83]

The named inscriber ends up in the code path in PatternContainerGroup.fromMachine() that consists of the last else block, there it checks if (target instanceof Nameable nameable && nameable.hasCustomName()). The first part is true, however nameable.hasCustomName() is null. This could be a bug. Note that target is the InscriberBlockEntity, not the block itself.

Funny enough PatternContainerGroup.fromMachine() is called for each side, even if nothing is attached there - except if there is a ME Interface there. Go back up in the call stack and find PatternProviderLogic.getTerminalGroup() calling getActiveSides(). There is a comment Skip sides with grid connections to other pattern providers and to interfaces connected to the same network and this could already be the explanation, as the Interface in full block form is on the same network as the Pattern Provider, while a ME Interface as a part (and not being connected to the main network by other means) is not.

[Mithi83]

Ok, on second thought it would be a very stupid idea to push items into a full block interface that would immediately put them back into the main network… So part 1 of the conclusions is „works as designed“ and not a bug. This leaves renamed Molecular Assemblers etc. as potential bugs. I‘ll have to trace the way from a block with a custom name to a block entity with a custom name to see if there is a bug there or not.

[Mithi83]

Some more debugging as to why the Inscriber in my example has no name: AEBaseBlockEntity.loadTag is

        if (data.contains("customName")) {
            this.customName = Component.literal(data.getString("customName"));
        } else {
            this.customName = null;
        }

In contrast to that the actual value of data is as follows:

Quick experiment to extract the proper name

        if (data.contains("components")) {
            CompoundTag components = data.getCompound("components");
            if (components.contains("minecraft:custom_name")) {
                this.customName = Component.literal(components.getString("minecraft:custom_name"));
            } else {
                this.customName = null;
            }
        } else {
            this.customName = null;
        }

This results in a customName of "TEST" (note that the double-quotes are actually part of the string and also show in the Pattern Access Terminal).