Describe the Bug

The half-slab copycat with glowstone will not make any light after we left the world.

Reproduction Steps

1. Put a half-slab copycat
2. Put glowstone texture
3. Leave your world
4. Join your world

Expected Result

It still should do light...

Screenshots and Videos

Crash Report or Log

No response

Operating System

Windows 11

Mod Version

0.5.1b

Minecraft Version

1.19.2

Forge Version

43.2.10

Other Mods

On the screenshot, there are:
canay
connectedness
create
create track map
ferritecore
framedblocks
immersive painting
jei
journeymap
kotlin
lazyduf
oculus
radon
reforgium
rubidium
rubidium extra
textruesrubidiumoptions
worldedit

But I also tried without all of them (just Create mod) and it still do that)

Additional Context

I tried to install Starlight mod, but it broke light so I removed it, (and deleted all minecraft files and all mods files etc)

After trying to spruce up a build and encountering this bug, I reported it, but seeing it's been a known issue for a while kinda bummed me out.
I feel like this is a somewhat high priority bug no? Letting players use this feature trusting it'll function, only to lose lighting in an area and potentially having mobs spawn can be quite the pain, imagine a complex contraption getting blown up or getting killed in hardcore because one used this light solution that seemed to work just fine.
This feature seems broken, so either a fix to make lighting work, or if all else fails, not allowing light emitting blocks to be copycats (which would suck but better than not working) is needed I feel.

Wait, this bug still isn't fixed? I just started updating mods on my server and was expecting this very serious bug that was reported almost a year ago to be fixed by now.

Wait, is this mod dead? The last commit seems to have been 2 months ago... That would be very disappointing, but it would explain the failure to fix such a massive bug.

The mod is not dead, If you look at https://github.com/Creators-of-Create/Create/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+bug%22 you will see many many bugs with many of them causing crashes and being higher priority then this.

Wait, this bug still isn't fixed? I just started updating mods on my server and was expecting this very serious bug that was reported almost a year ago to be fixed by now.

Wait, is this mod dead? The last commit seems to have been 2 months ago... That would be very disappointing, but it would explain the failure to fix such a massive bug.

After trying to spruce up a build and encountering this bug, I reported it, but seeing it's been a known issue for a while kinda bummed me out. I feel like this is a somewhat high priority bug no? Letting players use this feature trusting it'll function, only to lose lighting in an area and potentially having mobs spawn can be quite the pain, imagine a complex contraption getting blown up or getting killed in hardcore because one used this light solution that seemed to work just fine. This feature seems broken, so either a fix to make lighting work, or if all else fails, not allowing light emitting blocks to be copycats (which would suck but better than not working) is needed I feel.

Yeah, and it kinda sucks because it fully work well with Framed Block mod but this mod is a bit less opti with Create trains. Create contraptions are very usefull to do a lot of the Framed Blocks mod work without to make your game to die everytime your train stops in train station (I'm on laptop)

Wait, this bug still isn't fixed? I just started updating mods on my server and was expecting this very serious bug that was reported almost a year ago to be fixed by now.
Wait, is this mod dead? The last commit seems to have been 2 months ago... That would be very disappointing, but it would explain the failure to fix such a massive bug.

The mod is not dead, If you look at https://github.com/Creators-of-Create/Create/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+bug%22 you will see many many bugs with many of them causing crashes and being higher priority then this.

I agree that crashes are bad, but this is a huge gameplay issue. A mod that doesn't crash but has huge playability issues that pop up and surprise players isn't better than a mod that crashes occasionally but otherwise works as advertised. As a software developer myself, I can tell you that crashes are not always higher priority than basic usability problems. I don't know exactly how difficult this problem would be to fix, but I'll bet it's a lot easier to fix than most of your crash issues. Good prioritization is not just a function of severity. It's also a function of cost. A moderate usability problem that takes an hour to fix should often be higher priority than an occasional crash that is going to take days to debug.

That said, I'm not the author or a collaborator of the mod. It's your choice. But let me tell you: Create is advertised to be a high quality, and this is such a basic problem that has gone so long with no attention that I'm starting to feel like I was lied to. This mod has great potential. And I understand that you guy have limited time and a lot more issues than just this one. But fit and polish are a huge element of quality, and if you are going to present a product as being high quality when the polish is poor and not a priority, that's just not honest.

(And yes, I understand that I could fix it myself. I do have the skill to do that. And I appreciate that this is open source, giving me that option. Unfortunately, I absolutely loathe Java. If it wasn't for that, I would be making my own mods. In fact, I have dabbled, but each time Java made it so difficult I had to walk away to keep my sanity. I have a lot of respect for you for putting up with it, but I just can't bring myself to get involved. Thanks for taking the pain for the rest of us. As annoyed as I am about this bug, I really do appreciate all of the work you do on this!)

if you have the mod that removes ghost blocks (AntiGhost by Giselbaer) by requesting updates from the server, you don't even have to relog to see it stop producing light. It's super annoying, because I'd love to have copycat light sources.

Like AkacioBahno mentioned, it's not just glowstone. Any light block (including modded light sources) behaves the same way.

I believe I have found a (hacky) way to solve the issue. I added a line to toggle the LIT property of the copycat block's block state upon use (the LIT property doesn't affect the block, as far as I can tell), which solved the problem. I'm not really sure how the lighting engine works, but perhaps the server light not updating is due to the lack of a block state change. Adding in the toggle ensured that the block state changes every time you use the copycat panel/step, forcing a lighting update on the server side.

I have no clue if this is the best way to solve the problem and have not extensively tested the fix.

In CopycatBlock.java (I added the pState.setValue(...) line):

Edit: Nevermind. BetterF3 says the server light still did not update. Why does the light persist when I leave and rejoin the world, then?

Any other light emitting block doesn't work either and leaving and reentering chunks with copycat lights causes the issue aswell (not just reentering the world).

Issue still somewhat present in 1.20.1...

While walking with the debug info visible (F3) one can see there is a discrepancy between the light level of the client and the light level of the server.

While the light level appears to be correct, mobs will still spawn in a fully lit room lit with copycat blocks, breaking any usefulness as thin light sources!

This bug still exists in 0.5.1f, with MC version 1.20.1, and Forge 47.2.0.

As mentioned by @alkarym, the light level shows up correctly on the client but isn't correct on the server. This allows mobs to spawn in apparently brightly lit areas. Additionally, when playing on a dedicated server, the light levels show up correctly for the client (still not the server, as evidenced by mob spawns) initially, but if you log out and then log back in, the lower server light level is shown. Placing any light block and then removing it will return the client light level back to the correct level, but the server will still have the lower level as if the copycat light block was not there.

Hopefully the above details are useful, though I think it is pretty clear that the problem is that the light is being handled correctly client side but is completely ignored server side.

I believe I have found a (hacky) way to solve the issue. I added a line to toggle the LIT property of the copycat block's block state upon use (the LIT property doesn't affect the block, as far as I can tell), which solved the problem. I'm not really sure how the lighting engine works, but perhaps the server light not updating is due to the lack of a block state change. Adding in the toggle ensured that the block state changes every time you use the copycat panel/step, forcing a lighting update on the server side.

I have no clue if this is the best way to solve the problem and have not extensively tested the fix.

In CopycatBlock.java (I added the pState.setValue(...) line):

Edit: Nevermind. BetterF3 says the server light still did not update. Why does the light persist when I leave and rejoin the world, then?

and how did you edit file?

Would it be possible to add a block state that just stores the light level of the copycat, then change that block state whenever the material is changed?

I suggest this because the root problem is that copycats are block entities, which are unsafe to access in the light update worker threads. However, block states are accessible to the lighting engine (see: respawn anchor). So the possible fix would be an int block state called lightLevel that is changed according to the block placed in the copycat.

For the record, this is ultimately a Forge bug which cannot be fixed easily and cleanly in Create. NeoForge at some point past 1.20.1 made a fix, which will be used by Create on 1.21 and further. This is to say that this issue will not be fixed on 1.20.1 and will be fixed on 1.21 and newer.