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

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

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&

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

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.

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

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.

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.

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

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.

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.

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).

it's been a couple months and I'm trying to understand whether you all agree this is a feature that should be intended to work and is going to get some sort of fix since it's something that's been with ae2 since the beginning, or if this is working as intended and that the long standing feature is not something that's going to be accommodated moving forward or not?

I only ask cause I have reread all the replies here a couple times over the last couple of months and I'm not sure where it stands, yet the ticket remains open so I am curious.

Thanks

If it's still open after this long, you may generally assume that it will be considered at some point. Problem is, we don't know when that point will come since a lot of us involved with the mod are quite busy as of late with other matters in life outside of AE2.

If I interpret my previous ramblings correctly the correct way to do what you want (i.e. changing the names in the pattern access terminals) is renaming the machines attached to the pattern provider (e.g. molecular assemblers, inscribers, furnces etc). The remaining bug seems to be that the name is not correctly displayed in the pattern access terminal, despite being present on the machines. Since there is a rather lengthy chain which passes this information along I tried to find out where it breaks.

I'm not familiar enough with the code to propose a proper fix though and just hoped my analysis would help the maintainers to fix this bug in less of their own precious time, as they seem to be quite busy these days.

We'll look at this at some point, but it's not high priority and I am occupied with other stuff (NeoForge tooling)

it's always been renaming the interfaces (now providers)
it's the way ae has always treated this
it was there for example, if you had something like 8 towers of 8 interfaces and 32 moleculars each and wanted some sense of order while you were assigning where to put your patterns.
Now, all the towers are just grouped as one and there's no clear indication as to where you're putting your patterns without counting and hoping that they don't just shift at some point due to some other implementation

I see the issue you are having since you are now picking up the name from the pointed at machine

But moleculars are different and would require something else entirely to bring back the old behavior in whatever way was possible.

Thanks