Describe the bug
When Optifine is installed with PR Illumination, it causes (some) lamps not to illuminate on the client-side. Bug found in the Create A&B pack.

To Reproduce
Steps to reproduce the behavior:

1. Install PR and Optifine
2. Place a lamp
3. Check light level

Some lamps placed prior to installing Optifine remain lit, but breaking and replacing them causes them to no longer illuminate client-side.

Expected behavior
The client and server light levels should match.

Crash Log
Required for crash. DO NOT paste the entire crash log here. Use pastebin or similar.

Versions
Include versions of the dependencies. And since you're looking at it, make sure ProjectRed is up to date. Don't submit bugs for old versions, as they could have been fixed.

• CCL Version: CodeChickenLib-1.16.5-4.0.7.445-universal.jar
• FMP Version: CBMultipart-1.16.5-3.0.4.123-universal.jar
• MrTJPCore Version: NA
• ProjectRed Version: 1.16.5-4.12.0-beta-0 (core and illumination)

Screenshots/Videos
If applicable, add screenshots or video links to help explain your problem.

Can you confirm that this only happens with Optifine installed? Are there any cases where this bug appears without Optifine?

Bump. Any updates for this? Additionally, can you check if this happens with the full Lamp blocks as well?

This has happened to me too, originally the lamps worked fine with Optifine, placing them on my self-hosted server, after a restart when i went to play a few days later the lamps are now glowing, but not producing visible light on a client level, even the mod that shows light level is reading it as being no visible light.
Attempted to break all the lamps, replace the colour, try the full blocks, even restarted both my server and client however nothing fixed the lamps short of removing Optifine.
So yes this issue is Optifine related but thought I would share my experience too.

Optifine Version: HD G8 Ultra
PR Illumination Version: 1.16.5-4.12.0(issue tested on 4.11.0 as well with same result)

I hope this provided image helps diagnose the issue or at least answer your previous question:

Full sized lamp blocks:

• Both inverted and non-inverted are ALWAYS outputting block light regardless of redstone input.
• Applying a redstone signal will change the block texture but won't change the block light emission
• Presumably this is related to these blocks being full blocks and not part of microblocks.
• F3 HUD confirms that blocklight is 14 next to block

Fixture style blocks(microblock lamps):

• Includes Fixture/Fallout/Lantern/Cage types
• Both inverted and non-inverted NEVER output block light regardless of redstone input.
• Applying a redstone signal will change the block texture but won't change the block light emission
• Presumably this is related to these blocks being microblocks and not full blocks.
• F3 HUD confirms that blocklight is 0 next to block

Issue persists if Optifine is turned OFF(however still installed).

Vanilla Minecraft redstone lamps work as expected with redstone input.

I'm eager to help resolve this problem so please let me know if you need any additional information and I'll do what I can to provide it.

Addendum:

Here's another related shot of two torches occupying the same block with the microblock system. Note how no block light is emmited.

not exactly a solution but i recommend using Magnesium instead - it gives a significantly better performance boost.

it might still not be compatible but i'd at least try it.

My best guess based on these observations: Optifine is (incorrectly) assuming that light level does not change as long as the blockstate does not change.

Both PR lamps and all multipart-based tiles use the Tile Entity itself to determine light level, while keeping blockstate static. I could make that adjustment with lamps somewhat easily but it’s a little more difficult (maybe even out if the question) with multiparts.

Minecraft itself has no requirement for light level being tied to block state as far as I know.

How do normal redstone lamps work when Optifine is installed then? I would have assumed they operate basically the same

A redstone lamp uses a blockstate to indicate the light level output. When a redstone lamp changes it's blockstate Optifine will detect the blockstate change and update the lighting in it's own way(Optifine overrides important Minecraft rendering code for one reason or another, likely for performance or for the data to become accessible to a shader program).

Conversely a microblock light(the non-full-block lights used by Project Red Illumination) uses a TileEntity to store the light data so when it's internally managed light value changes there's no blockstate change to be detected by Optifine. Normally the light would be available to Minecraft via the block's position sensitve method: getLightBlock(BlockState, IBlockReader, BlockPos). Somehow Optifine breaks this.

I'm assuming that @MrTJP has considered(or is indeed already) marking a block position in the world as dirty when it's internal state changes for lighting.

One possible workaround(hack) would be to have 2 identically functioning blockstates used for microblocks and just flip-flop between them when the state of a microblock tileEntity changes. This isn't ideal but might work.

@ferreusveritas Are you confirming that that is indeed the logic that Optifine is using, or just speculating?

If there is some fundamental Minecraft requirement for light levels to be bound to block state, then Multipart blocks should actually have a Light Level property. If it's just an Optifine assumption, I'd argue it is not correct.

This was speculation about Optifine and how it might be optimizing. I agree with you that Optifine may be using blockstate changes as an event to recalc light and remesh chunks. This is new for 1.16.5(as opposed to 1.12.2 where Optifine worked fine with Project Red Illumination). Since 1.16.5 has focused maniacally on blockstates I think it has afforded tech like Optifine to make some assumptions it shouldn't be making. There are no TileEntity based lighting solutions in vanilla Minecraft.

Instead of guessing I'll do some research to get a better understanding of what's going on.

A solution to this problem could be to port ProjectRed to Fabric, which would allow the use of sodium, iris (which would allow the use of ProjectRed with shaders) and other optimization mods (I think they would work without any problems), and Fabric is lighter than Forge anyway. But depending on how the mod works, it could be a lot of work.

@MrTJP I did some research comparing Forge to Optifine code and tracing the calls for both. Here's what I have learned:

• Vanilla Minecraft uses blockstates exclusively for light emission. The light emission is a property of a blockstate, not blocks.
• Forge overrides vanilla method behavior with block position sensitive methods in several locations(I have notes if interested).
• Optifine's rendering methods undo the position sensitive methods in Forge and replace it with vanilla style blockstate light.(also notes)

Therefor if the goal is to make Project Red Illumination work with Optifine then two alternatives are the most immediately obvious to me:

• Optifine could fix it's rendering code to respect the position sensitive block light methods developed by forge. After all this really is Optifine's fault for breaking this behavior and it should fall on them to fix, only this will probably never happen since light levels derived from TileEntity data is more-or-less a rarity in the modding community.
• Project Red Illumination could use 2 blockstates for microblocks. One with light level 15, another with 0. The blockstate could be changed to one or the other depending on the TileEntity light state. This is assuming that an emitting microblock light will generally only emit light at level 15(this is the only state for lit PR lamps AFAIK). If perfect compatibility with torches is desired then another blockstate with a light level of 14 would need implemented, although using 15 instead would probably be unnoticable TBH. This also has the advantage of being automatically compatible with practically everything.