When entering a portal, the portal generated on the other side generates with minecraft:stone_bricks instead of using the undergarden:portal_frame_blocks tag.

For example, changing the contents of undergarden:portal_frame_blocks to mekanism:block_charcoal, portals still generate with minecraft:stone_bricks, but, if broken, can not be relit.

I suspect that relevant lines are UGTeleporter.java#L118 and UGTeleporter.java#L130, but I'm not knowledgeable enough about mod dev to know what to replace Blocks.STONE_BRICKS with.

@nerdywhiteguy consider this, since tags can have multiple blocks specified in it, how would a new portal autogenerated know which block to use? Would pick a randomly one to use for the whole portal? Would it just use all the blocks randomly for the portal?

Basically, I think the tag was more for user created portals and not so much as for the portal that’s autogenerated. Otherwise, some thinking is going to have to be done for how the autogenerated portal will behave with the portal block tag.

I would tend to think that using a single block for the whole portal would look best. I'd also pick the block to use deterministically based on the location in the world to allow portals to be recreated consistently. Perhaps something to the effect of tag[ (portal.x + portal.y + portal.z) % tag.length ]?

To allow the default behavior of always generating a portal with minecraft:stone_bricks to remain the same, even if more blocks are in the undergarden:portal_frame_blocks tag, I propose creating a new tag, perhaps named undergarden:generated_portal_frame_blocks, which will default to just containing minecraft:stone_bricks. (If this tag is blank, it will be automatically filled with the contents of undergarden:portal_frame_blocks at runtime.) Thus, on the surface, the mod's behavior will not have changed, but modpack authors will have more configuration.

implemented in 56e9c65