Whenever I get into the game, I manually /ll, then /ll mode Spawnable. I usually facepalm that I've forgotten after some related event when I'm wondering why I didn't see a spawnable spot. So this request is to save the player setting when changed, (enabled status and mode), and refresh the last recorded setting when the player comes back into game.

I've never looked at the source for this plugin but I'd be happy to fork and see if I can make the changes myself for PR.

I believe the change would need to check the player permissions prior to resetting. Example scenario: Player has permissions, makes a change, then loses permissions. Logout/in, and EL is enabled again. When this new refresh code is executed on player join, if the user does not have permissions to use EL, I believe the previous setting should be cleared. This would also stop someone without permissions from quitting, changing the config file, then coming back in to get functionality.

Thanks!

In the nether Iron Bars (fences, not ingots) show with red particles. The iron_bar object is transparent and thus non-spawnable. I'd like to see this item set as non-spawnable, but I'm wondering if other objects like it need to be checked too.

Ref: https://minecraft.gamepedia.com/Opacity

Mobs cannot spawn on transparent blocks, nor even spawn inside opaque blocks. However, they can spawn inside a non-solid transparent block, such as flowers.

Also on that page, iron_bar objects are categorized as "Non-Full-Block Solids" compared to "Non-Solids". So this object is not subject to that exception.

Therefore, iron_bars should not be spawnable, and neither should anything else in the list of transparent solid blocks.

Thanks!

I appreciate the PR for the README regarding permissions. However, if we just update permissions.yml as documented now the following error results on server startup:

ERROR]: Permission in permissions.yml was already defined
java.lang.IllegalArgumentException: The permission eternallight.target is already defined!

I can look at this if required. Anyone else?

Where tickets #8, #9, and #10 are related to limiting scanning to what we Can see, this is about scanning what we Cannot see. We can get audio cues and use subtitles to get the rough x,z direction of a mob. But that tells us nothing about their Y location or distance. To find mobs behind walls, start digging in the direction of the sound, and dig up and down along a path until you find a place big enough for mobs to spawn.

With this ticket I'm requesting a mode where the UI tells us the x,y,z offset of spawnable blocks within a specified radius. I don't have a firm thought about what the UI should look like. The idea is that I'd like to know if there is a spawnable block along a specific vector even if I can't see it. There might be a gap 3 blocks to my left and 2 blocks down - that would be a -3,-2,0 offset. Maybe the UI can render that offset in the block in front of the player when this mode is activated. That indicator would only show the closest spawnable block. Once a block is found and an offset rendered, stop doing this scan - it's always looking for just one block starting from the player location and moving outward.

Rather than using /ll commands, this mode might be active if the player has some object in the offhand, maybe a torch. This technique might be applied to change behaviour as requested in the other tickets. So, with mode Spawnable, if a torch is in the offhand, find spawnable blocks that are not visible, and without the torch, scan as normal.

I've written my own plugin to find mobs within a range, using subtitles to reference their x,y,z offset. That's a bit 'cheaty'. In this case, it fits with the EL purpose to find dark places - it's not repurposing to find mobs.

Thanks!

Rather than scanning a spherical radius or a full rectangle/cube around the player position, consider only scanning along the vector where the player is looking. For each block of the LoS vector, scan +/-2 of the block x,y,z. This would be like putting your eye to a telescope to see only what is in your viewing direction.

Combine this with #8 and #9, where the radius of a limited scan can be much longer than a full scan in all directions from the player position.

Sometimes it doesn't make sense to do a spherical scan so I'm hoping we can disable this with a ```/ll mode`` .
The goal is to eliminate processing cycles that are unnecessary.

Examples:

• In a cave where we are strip mining and there is only exposed space before and behind, not above or below. Yes, we can open into a cavern where we will want to see what's spawnable but then we can change the setting.
• On the ground where there is nothing but air above, there's no sense in looking for blocks to test. And we might not care what is below us, hidden underground and out of sight.

I haven't looked at the code but maybe an enhancement like this would help: Start scanning at the current Y and scan down and up by +1 and -1. Only proceed to the next +/-Y if there is >=1 transparent block which allows us to see to that Y. Similarly, stop scanning along a specific vector as soon as line of sight is blocked. So if we are in a solid 4x4x2 box, there's no sense in scanning up, down, or beyond the 4x4 border.

Then again, checking every block in the entire sphere might be faster than doing these other tests. And for all I know you're already doing exactly this. :)

I know we can disable spherical scanning. I don't know if this reduces the scan as I've described or if it just makes the scan a rectangle of Radius*Height.

Maybe a better explanation for this request would be : Check to see if a block is in a vector with line of sight first, before determining if it is spawnable, because if we can't see the particles, there's no sense in calculating the spawnability.

Please add option to disable the updater or remove it. Thanks

19:46:40 WARN: at net.axeora.eternallight.util.VersionChecker$VersionMeta.(VersionChecker.java:62)
19:46:40 WARN: at net.axeora.eternallight.util.VersionChecker.lambda$run$1(VersionChecker.java:37)
19:46:40 WARN: at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
19:46:40 WARN: at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
19:46:40 WARN: at java.lang.Thread.run(Unknown Source)
19:46:40 WARN: [EternalLight] Failed to check plugin version. Are you running offline?

Thank you for making this mod. This is going to be a huge help.

The maximum scan radius is set in EternalLightConfig.java. On a hefty server, like a modern PC with only 1-2 players, the default hardcoded limit of 20 is frustrating. Yes, I can change that and build from source but there's a better way to do this.

By reading the RAD_MAX from the config file, like the other fields, every admin will have the ability to decide what fits their environment.

This relates to #8 where we might want a 50 block radius for our direct line of sight, and we don't care what is above or below us. We certainly would not want a full 50 block radius in a cavern or rugged terrain, but in a more enclosed area where we are not going to scan a full sphere, 50 blocks straight in the direction we are looking isn't bad at all.

As a server admin, I would like to give my players the ability to use this plugin. However, there doesn't seem to be any documentation on how to set these permissions. Putting eternallight.admin/use/mode in config.yml ends up with a bunch of errors flooding the console and then when I return to the file it has been reset to default. More explanation would be fantastic.

Someone in the Spigot discussion area noted that something in 1.19.3 might have broken this plugin and others.
Eternal-Light 1.8 is not working in MC 1.19.4. We can set the config file and issue /LL commands but everything is ignored and there is no change to the UI to show light levels. No errors are reported in the server console.

I can look at this if required. Anyone else?

TY

Getting the attached console error when toggling /ll. Any help appreciated.
error.txt

Support the new change in 1.18 by showing red particals at blocks with a light level of 0.

The current behavior is showing red particals in light levels of 1-7 but mobs are not able to spawn.

Note that mobs still spawn in a skylight of 0-7 assuming blocklight is still 0.