Dynamic Lights & Colored Lights Core

[givemhell]

it seems that when you use Dynamic Lights mod with Colored Lights Core it does not render light from torches or other objects, granted it would be cool to see you support Colored Lights & movement but id just like to see the minor bug fixed =]

Link to Dynamic Light Mod - http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272478-dynamic-lights-portable-and-moving-lightsources

[CptSpaceToaster]

Most of the logic used inside DynamicLights strips out the color from the lightvalue integers, resulting in light that is rendered "black" by the CLC. I created an expectation for lightvalue integers, and it's not preserved in DynamicLights.

Last I recall, it also uses its own updateLightByType() method to spread light values around in specific instances to facilitate the dynamic movement. This method is also not compatible with CLC.

I can't fix this one on my end, unless they started relying on vanilla methods again................ or altered their source unnecessarily.

Lightvalue bitpacking
S = Sunlight Bit
B = Blue light Bit
G = Green light Bit
R = Red light Bit
L = Vanilla "brightness" Bit

Vanilla:        0000 0000 SSSS 0000 0000 0000 LLLL 0000
CLC:            0000 0000 SSSS BBBB GGGG RRRR LLLL 0000
Dynamic Lights: 0000 0000 SSSS 0000 0000 0000 LLLL 0000

The CLC modifies the vanilla lighting engine to spread around these color bits, and also modifies the renderer to accept them. The ligthing engine is quite robust and hard to break, but in this case... if Dynamic Lights provides their own... then I can't do anything about it.

The renderer was modified to "Ignore" the L bits. Instead, a color mask is applied over the drawn vertexes using the B, G, and R bits. When dynamic lights does their own thing, the renderer will draw a block, ignore the L value that Dynamic Lights put there, and then it will draw "no color" because the R, G, and B bits were removed/never put there in the first place.

[givemhell]

im going to link this page to the other mod author and see if there is anything he can do about it thanks for the quick reply!

[AtomicStryker]

Ok so as far i remember Dynamic Lights uses ASM to override the following line in World.computeLightValue: int blockLight = block.getLightValue(xxx); -> int blockLight = DynamicLights.getLightValue(xxx). Dynamic Lights internally uses the same block.getLightValue(xxx); to get the vanilla value. I'm assuming you have overridden getLightValue(xxx) further "down" the pipeline. My source looks like this: https://code.google.com/p/atomicstrykers-minecraft-mods/source/browse/DynamicLights/src/main/java/atomicstryker/dynamiclights/client/DynamicLights.java#156

I assume i can fix this by either detecting color bits in the int or changing the light.getLightSource().getLightLevel() result to flip its bits into the vanilla int instead of overwriting it. Do you concur?

[AtomicStryker]

I have now checked out your repo and you completely replace computeLightValue in your ASM. It appears if this is to be fixed, it has to be done from your side.

[givemhell]

wow you both are extremely active and reply fast, thank you both for the support =]
i hope this will be resolved soon!

[CptSpaceToaster]

@AtomicStryker If I understand it, then it looks as if I'd need to simply check to see if DynamicLights is loaded, then simply replace my calls to block.getLightValue() with your atomicstryker.dynamiclights.client.DynamicLights.getLightValue()

Sound right?

[AtomicStryker]

That is correct.

[CptSpaceToaster]

@AtomicStryker In both functions? Or only computeLightValue? The other being: updateLightByType() I'm not seeing how that fixes everything... But I can move forward with the integration regardless......

[AtomicStryker]

Well, i only hook into the one function, and its enough for Dynamic Lights to work. I can only speculate why you need 2, but since Dynamic Lights internally queries block.getLightValue(xxx); anyway, at worst you add some overhead.

[CptSpaceToaster]

I think I'm reflecting into it incorrectly... looking into this.

[CptSpaceToaster]

@AtomicStryker
Ok... learned a lot... I'm actually referencing the method properly now.

And... something is still stomping on the color bits
https://code.google.com/p/atomicstrykers-minecraft-mods/source/browse/DynamicLights/src/main/java/atomicstryker/dynamiclights/client/IDynamicLightSource.java#34

I don't know who's limiting to 15, but if that happens, then the color bits in the light value are lost.

LightValues are stored as

0BBBB 0GGGG 0RRRR 0LLLL

and they're being capped to 0b1111. A torch which is colored a bit yellow should normally return

01010 01101 01110 01110

(decimal: 341454) and a ceiling is being applied, and causing it to return decimal 15, meaning a torch is receiving a vanilla light value that is greater than intended...

Ideally, I should find the limit, and simply remove it for CLC purposes. If the limit still needs to exist outside of CLC, then applying

return lightValue & 0xF;

is a little safer as that would return the expected vanilla value of 14 even in the presence of CLC. Do you have any idea where this ceiling is coming from?

[AtomicStryker]

15? It's a design choice. Notch said "let there be light, in full integer increments of 0 to 15". The idea was probably to use an efficient data storage of 4 bits