java.lang.ClassCastException: nms.v1_15_R1.LightEngineLayerEventListener$Void cannot be cast to nms.v1_15_R1.LightEngineSky about lightapi HOT 22 CLOSED

But I do not understand yet how it is possible (the world does not have light engine)

Light engine exists, but does not store information about skylight.
This is possible in worlds where there is no sun. For example the nether or the end worlds

from lightapi.

Hmm,,, very strange =
Have you find mistake?
Why did you close issue?

from lightapi.

I think I found out the issue, apparently, I can can't mixed skylight update chunkinfo and blocklight update chunkinfo together.

I can't really produce the error myself, but I made the change blindly and users reported that it worked.

from lightapi.

Hmm...
The exception was in LightAPI.deleteLight (not in LightAPI.updateChunk)
And the problem was that there were no "light engine" for sky at that world
I think this is my bug that I do not check the absence of light engine in the world.
I should have expected such behavior and made at least a more friendly handling of such situation

But I do not understand yet how it is possible (the world does not have light engine)
Hmm.. I should make some tests if some worlds does not have sky/block light engines... Hm.. very strange =\

Also I wonder how you was able to mix sky and block create/delete/update because the semantics of API does not allow it.
And mixed calls like:
createLight(... LightType.BLOCK ...)
createLight(... LightType.SKY ...)
deleteLight(... LightType.BLOCK ...)
deleteLight(... LightType.SKY ...)
updateLight(... LightType.BLOCK ...)
updateLight(... LightType.SKY ...)
should be legal

from lightapi.

Oh, then perhaps there are some other problems, but these are the parts which I changed:

Before:

if (changed) {
	HashSet<ChunkInfo> infos = new HashSet<ChunkInfo>();
	for (Location location : locations) {
		infos.addAll(LightAPI.collectChunks(location, LightType.SKY, 15));
		infos.addAll(LightAPI.collectChunks(location, LightType.BLOCK, 15));
	}
	for (ChunkInfo info : infos) {
		LightAPI.updateChunk(info, LightType.SKY);
		LightAPI.updateChunk(info, LightType.BLOCK);
	}
}

After:

if (changed) {
	HashSet<ChunkInfo> blockinfos = new HashSet<ChunkInfo>();
	HashSet<ChunkInfo> skyinfos = new HashSet<ChunkInfo>();
	for (Location location : locations) {
		skyinfos.addAll(LightAPI.collectChunks(location, LightType.SKY, 15));
		blockinfos.addAll(LightAPI.collectChunks(location, LightType.BLOCK, 15));
	}
	for (ChunkInfo info : skyinfos) {
		LightAPI.updateChunk(info, LightType.SKY);
	}
	for (ChunkInfo info : blockinfos) {
		LightAPI.updateChunk(info, LightType.BLOCK);
	}
}

from lightapi.

Thanks
Your both parts are legal except that it is not optimuzed =)

You collect and update chunks both with sky and block types and with the same level 15 without paying attention to where, what level and what type of lights were exactly created
There will be too many extra chunks for updating, in which the light did not really change.

You do not need to update chunks for BLOCK light if you you have set only SKY lights. And vice versa.

Also you do not need to collect chunks for level 15 if you have set lights only (for example) with level 7. The light spreading with level 7 affects fewer chunks than with level 15 (distance 7 < 15)

from lightapi.

I think you've got it right, the problem only occurs in the nether as well as the end.

from lightapi.

Yes confirmed. the nether and the end do not have sky light engine 😄
I have tested on several bukkit versions
So, it is my bug. I will think how to solve it more friendly

PS. versions prior 1.14 also do not set sky lights in the nether and the end. But my api does not throw exception because there is another light mechanics in bukkit.

Thanks that you found this issue

from lightapi.

Could you test your plugin in the end or nether without lights.
I want to see if items are darked in your hidden armostands stucked in the block there (the nether and the end)

from lightapi.

I've done some testing and the armorstands does not darkens fully in the nether. The "darkest" it can get is visually around light level 7.

from lightapi.

I guess I can add a check in my plugin to not attempt to modify skylight in the nether and the end.

boolean changed = false;
Set<Location> locations = new HashSet<Location>();
if (!deletequeue.isEmpty()) {
	changed = true;
}
while (!deletequeue.isEmpty()) {
	Location location = deletequeue.poll();
	if (location != null) {
	if (location.getWorld().getEnvironment().equals(Environment.NORMAL)) {
		LightAPI.deleteLight(location, LightType.SKY, false);
	}
	LightAPI.deleteLight(location, LightType.BLOCK, false);
	locations.add(location);
	}
}
if (!skylights.isEmpty()) {
	changed = true;
}
for (Entry<Location, Integer> entry : skylights.entrySet()) {
	Location location = entry.getKey();
	if (location.getWorld().getEnvironment().equals(Environment.NORMAL)) {
		int lightlevel = entry.getValue();
		LightAPI.createLight(location, LightType.SKY, lightlevel, false);
		locations.add(location);
	}
}
if (!blocklights.isEmpty()) {
	changed = true;
}
for (Entry<Location, Integer> entry : blocklights.entrySet()) {
	Location location = entry.getKey();
	int lightlevel = entry.getValue();
	LightAPI.createLight(location, LightType.BLOCK, lightlevel, false);
	locations.add(location);
}
if (changed) {
	HashSet<ChunkInfo> blockinfos = new HashSet<ChunkInfo>();
	HashSet<ChunkInfo> skyinfos = new HashSet<ChunkInfo>();
	for (Location location : locations) {
		skyinfos.addAll(LightAPI.collectChunks(location, LightType.SKY, 1));
		blockinfos.addAll(LightAPI.collectChunks(location, LightType.BLOCK, 1));
	}
	for (ChunkInfo info : skyinfos) {
		LightAPI.updateChunk(info, LightType.SKY);
	}
	for (ChunkInfo info : blockinfos) {
		LightAPI.updateChunk(info, LightType.BLOCK);
	}
}

Btw can I just do this? :

skyinfos.addAll(LightAPI.collectChunks(location, LightType.SKY, 1));
blockinfos.addAll(LightAPI.collectChunks(location, LightType.BLOCK, 1));

as I really only have to update light in the block itself. (And it worked while testing)

from lightapi.

skyinfos.addAll(LightAPI.collectChunks(location, LightType.SKY, 1));
blockinfos.addAll(LightAPI.collectChunks(location, LightType.BLOCK, 1));

This is not exactly right way.
I wonder when you said "And it worked while testing"

These calls say:
"Give me please all chunks that client should update after I have changed light at this location to light level 1".

But this is not true. You have changed light level not to 1 but to "lightLevel".
For example you have changed light level to 12 at location 16:16:16. The light spreading has occured from 16-(12-1) to 16+(12-1) in x,y,z directions (LightType.BLOCK). This means that light was changed at blocks from 5:5:5 to 27:27:27. and client should reload lights in 8 chunks:
0:0:0, 0:0:1, 0:1:0, 0:1:1, 1:0:0, 1:0:1, 1:1:0, 1:1:1

But you told to collect chunks like you set light level 1. Therefore collectChunks will return only one chunk 1:1:1 because according your words blocks were affected from 16-(1-1) to 16+(1-1) = 16:16:16.

What will be next:
You have collected only one chunk 1:1:1. Then you call updateChunk and client will recieve info that only one chunk need to be updated. It updates this chunk and the player will see changes only in this chunk. He will see the sharp transition of light on the border of the chunk.
Then when player go far away and come back to this loaction, chunks will be reloaded and the player now will see all 8 chunks with light spreading as intended.

I can be wrong, but I think I'm not wrong

from lightapi.

I see what you mean, but since I'm just taking the light level - 1 of the block above, there wouldn't be any sharp edges. Tho I'm afraid that it would create ghost lighting caused by desync, so I guess I'll still have to change it. I'll leave it at 15 for now.

How do you plan on dealing with skylight in the nether and the end?

from lightapi.

All that I can do:

1. Check this situation and do nothing if the light engine of the specified LightType does not exist in the wolrd.
2. Add helper function to LightAPI to check if world supports specified LightType

Also, you wrote:
I've done some testing and the armorstands does not darkens fully in the nether. The "darkest" it can get is visually around light level 7.
I do not understand what you mean with word "fully" and about light level 7 + darkest.
Could you post here screenshots how it looks like?

from lightapi.

Basically what I meant is that, in the normal nether, even at a light level of 0, it looks like light level 7, that's why even if you block yourself up, it is still rather bright in the nether. So the same applies to the darkening of armorstands inside a block.

from lightapi.

Notes:
1, BLOCK light is spreading in all 6 direction with decreasing by 1 each block.
2, SKY light in 1.14 and newer is spreading with decreasing by 1 each block only in south,north,west,east and up. It is spreading down (until non-transparent block) WITHOUT decreasing its level. In 1.13 and below SKY light is spreading like BLOCK light.

But your plugin should still use level-1 from upper block both for block and sky light because you want only one chunk to be updated. Therefore it must be less than nearby light to prevent spreading

from lightapi.

More notes:

1. In 1.14 and newer versions light can not be set in chunk section (16x16x16) if this section and all 26 nearby sections are empty (only air). Bukkit does not hold the light storage matrix (NibbleArray) for that section.
   Unfortunately I do not know yet how to create missing NibbleArray for section. Once I have tried and broke the data consistency in data storage. Only deleting the mca-file has fixed this error 😄

2. In 1.13 and older versions you can set light from 0 to 255 in y-direction. In 1.14 and newer versions you can set light from -15 to 271 even when you can not set general blocks there. In other words if 1.13 and older have 16 sections in chunk for lighting, then 1.14 and newer have 18 sections. So, it gives you ability to enlight blocks in the world from outside the world. 😃

from lightapi.

Hi
I am going to add method

boolean LightAPI.isSupported(World world, LightType lightType);

Is it good name and semantics?

from lightapi.

Seems good to me. I can use this check instead of checking the environment.

from lightapi.

Be patient please
I am now going to test new update before push to git and maven repository

from lightapi.

Alright. Thanks.

from lightapi.

Yes! I was stucked with deploying to maven repository (forgot how to do it 😄). But now I have remembered
So,

1. Tested under 1.8 - 1.15 bukkit servers - OK
2. Commited to github - OK
3. Posted to spigot - OK
4. Deployed to maven repository - OK

from lightapi.