First I would like to say that this is a great mod! :D

I was trying to "cannon" out a schematic that I made using the Create Mod. There seems to be an issue with how the WallLanternItem works. The cannon requests the WallLanternItem, but this is not a valid item (in its GUI it says "you shouldn't have gotten this item")

Not sure if this is an issue with Create or this, but a quick scan through the code showed me you do some custom stuff if a "minecraft:lantern" is placed.

Let me know if I need to PR this, not sure how to fix this tho.
The easy way would be to "enable" the WallLanternItem and add a simple conversion recipe between minecraft's lantern (and back). You can still use the default minecraft lantern to place wall lanterns, but when an external mod requires the wall lantern item it would be easy to get the item.

So basically wall lanterns have an associated block item that helps me handle the placement behaviour. Apart from that it is never used. Honestly I think it's a create issue since it seems to me it should not try to convert a block to it's block item but instead ask it what it wants instead using the pick block method. That's what the one probe and other similar mod use for example and it correctly shows the item corresponding to that. Of course I'm not exactly sure how that cannon works but unless it simulates player placement of a block when placing it down (and thus calling my forge event methods that override the lantern placement behaviour), this will never work. Yes your conversion recipe would of course solve this but it would require me to add and register a wall lantern item dynamically (usually not the best of ideas but it can be done) for every possible modded lantern which also raises the question of what its icon should be. I might add such a thing as as an optional config if I don't find a better solution. Let me know if you have any other ideas

Actually a correction: the schematic cannon is probably using the function block.asItem which pairs every block n associated item, which is not an itemstack and thus can't have nbt. Since there is only 1 wall lantern block that I am adding I could associate it with a normal wall lantern item but that would leave out eveyr other kind of item like soul lanterns for example. The only option to make this this work would be to register wall lanterns blocks dynamically too, which again forge discourages. I have seen some people do it but apart from this niche application I don't see any other benefit from this. Still I'll look into it

Yeah I thinks this is really a strange edge case. I will also look into this and see if I can find an "optimal" solution :D

(I'll check both Create source and this repo to see what is exactly causing this behavior)

By the way, as a mitigation I used this command in my single player world:
/give @p supplementaries:wall_lantern

As a mod software dev I have no issues with fixing this through commands, I simply "delete" a few lantern that would've been used otherwise. This is not a nice option for "normal survival players" or even for players that have no access to the /give command

Well actually that item alone won't do the trick. It might work for normal lanterns (since the wall lantern tile defaults it's internal lantern blockstate field to the default lantern) but won't work for all the others

I did some reading through the Create source, and it seems to be using the net.minecraft.world.gen.feature.template.Template class. Which obviously is a minecraft internal class, which would be hard to modify.

The "simple" solution would be to create multiple instances of WallLanternBlock for each "lantern like" block we find.

After some more looking into the source code, I think I have 2 solutions.

Give WallLanternBlock an item block reference

Using this method you would store the type of lantern in the block state instead of within the TileEntity. This will break existing worlds though, and you might want to wait on 1.17/world height update or something that will also probably break existing worlds. This is not really a nice solution I think.

Optional dependency on Create

This might be something you don't want, as depending on different mods will make code maintenance more difficult. This will however allow us to "fix" some other compat issues as well.

The other issues I talked about are no big issues (talking about hanging sign not being able to remember held item). I would think the same issues arise with any "nbt" holding tile entity. (Like jars)
having access to com.simibubi.create.content.schematics.ISpecialBlockItemRequirement will allow us to override the item requirement, and will also solve the hanging sign issues as we can simply add the held item to the requirements lists. When properly implemented we can simply add a tag to the blocks that specifies we want to save the NBT. See AllTags.java. It seems this tag is used for blocks that are "safe" to restore the NBT to without creating an item dupe issue. Properly implementing ISpecialBlockItemRequirement should make it safe to restore the NBT