Add illumination feature to `#sel` commands

[nbyrd]

Describe your suggestion

The #sel command should have an "illuminate" option. #sel illuminate would use torches and/or other light-emitting blocks (glowstone, redstone torches, beacons (?), lava (????), etc.) to light up the selected area(s). By default, it should light up every surface area enough to prevent mob spawns; but it should also take an argument to illuminate the area to a selected level.

Examples

#sel illuminate - Light up the selected area with basic torches enough to prevent mob spawns. #sel illuminate 10 - Light up the selected area to a minimum light level of 10. #sel illuminate glowstone - Light up the selected area enough to prevent mobs from spawning using only glowstone blocks. #sel illuminate redstone_torch beacon 3 - Illuminate the area to a light level of at least 3, using only redstone torches and beacons.

Perhaps there could also be a similar command or configuration to remove all light from an area. #sel illuminate 0, perhaps? However, there are already workarounds that can achieve this result (mine torches, replace lava with stone, etc)

Context

It's would be a handy feature for construction projects where you want something to be lit up, either for aesthetic purposes or to guide/restrict the spawning of monsters.

Final checklist

• [x] I know how to properly use check boxes
• [x] I have not used any OwO's or UwU's in this issue.

[5HT2]

Duplicate of #971, you can use any command in a #sel area

[SeasonalFerret]

I would like to argue that this is separate from #971 and to re-open this issue.

971 is about having baritone automatically place torches while pathing.

1347 (this issue) is about SELECTING an area to torch up.

One is similar to backfill, which is nice as it keeps mobs from spawning in tunnels while mining for ores. However, the other one is for ACTUALLY lighting up an area that the user may have created before-hand.

Example of #971: -You want diamonds -You don't want mobs spawning in your tunnel -Use #autotorch -Baritone will now place torches as it's mining

Example of #1347 -You're building a mob grinder -There's lots of caves everywhere, where mobs are spawning, and you want to get rid of them all so your mob spawner is more efficient -#sel pos1, #sel pos2, #sel torcharea -Baritone should look for all dark spots / mob-spawnable-spots in the selected area, and path to them, placing torches along the way

Although arguably you can do this with #971, this would require you to path baritone to said dark spots yourself or to use baritone to construct the base first with #autotorch enabled preemptively.

I would VERY much love a mod/plugin/program that could torch my base for me. Having a program that can automatically torch up a base has NEVER BEEN DONE BEFORE. I can't even find a worldedit plugin or script that does this, so this would be absolutely amazing.

[SeasonalFerret]

As I said, this would be AMAZING. I've been looking for a program that could do this ever since 1.6 (yes, 1.6, not 1.16) came out, and I've never found anything other than a stupid forge mod that places a torch at your foot when you walk over a dark spot, which is stupid.

How this could potentially work: -Search the selection for light level LOWER THAN 8 -Path to closest -Place a torch on that block -Recalculate light level nearby (~10 blocks)

Expected result: -Baritone should run around the surface lighting the area up first, including inside of buildings. PREFERABLY do not break any blocks at first? It would be stupid if baritone broke into the side of my wall just to put a torch there, so have a high block breaking penalty. -Baritone should then path towards cave_air (air that only spawns in caves during world generation- look it up, you can probably use this) and path towards the closest dark spot inside cave_air, then begin the steps all over. Torching the area should be finished when there are no air blocks (cave or otherwise) with a light level less than 8.

It's probably recommended to torch the tunnels baritone digs as well, but I'd assume that it would do this anyway as long as baritone recalculates all of the light levels within the selection one last time when it thinks it's finished?

I know this probably sounds tedious and is probably hell to code baritone to detect light levels, but if done this would be the first ever program to ever auto-torch an area. No plugin can do this, no worldedit script can do this.

We don't need to use glowstone, since random blocks of glowstone laying on the ground would be really off.

[SeasonalFerret]

I hope I don't sound desperate/impatient, but could I get an opinion from a developer on this #sel torcharea feature?

[5HT2]

I see it as being very specific for the amount of time it would take to add to baritone, should anyone like to add it

[wagyourtail]

If you want to light up an area with minimal amount of torches the math might get a bit complicated, meaning it's harder to implement a "good" version.

[SeasonalFerret]

If you want to light up an area with minimal amount of torches the math might get a bit complicated, meaning it's harder to implement a "good" version.

A "bad" version that uses up many torches is better than no version.

1. path to a block with light level 8 (within the selected area)
2. place torch at your feet
3. repeat

I would imagine that this would work just fine for many users. If a player is trying to "torch up an entire area", they're bound to have plenty of torches ready for the job. Comparing this method to a person who just spams torches everywhere randomly, this would still not only save torches but also time since baritone would be able to tell where caves are and path to them efficiently while a legit player can not.

Personally, my intended purpose of such a feature would be to fill in caves within a large area in order to make my mob farm more efficient. I could care less if it spams torches everywhere in caves that I will not be going into personally, as long as it covers up all dark spots. It could fill the entire area with pressure plates for all I care- as long as it prevents mobs from spawning in order to increase my mob farm efficiency.

[SeasonalFerret]

Can't use WorldEdit because I'm not op. Can't use MCEdit because that project died 3 years ago.

I think the best thing I can personally do is to use a world-downloader mod to download the multiplayer world, host a local 1.16.5 server with the downloaded world and connect to it using MC 1.8.9 with via-version with another world downloader (the most popular one requiring you to find a download of java 6, as it does not work on later versions of java), then up in mcedit and run this autotorch script someone happened to have made over six years ago, then remove all blocks except the torches, then convert the final world as a .schematic file, then use litematica to preview the blocks back in the multiplayer world and line them up, then have baritone .build the torch schematic.

That, or take some java classes and learn how to make baritone "walk to nearest dark spot and place a torch". T~T

[scorbett123]

Duplicate of #863

[SeasonalFerret]

@scorbett123 Shouldn't you keep the issue with the most information open? Sure, #863 is older, but this one has actual examples and further information in comments. #863 literally has nothing.

[scorbett123]

Ok I'll swap it if you insist, however it really doesn't matter.

[Sp3rick]

its been added?

[scorbett123]

its been added?

This feature hasn't been added yet.

[PlasmaHH]

Just found this while wanting to suggest a rather similar feature... it would be extremely handy if one could make baritone automatically light up a sphere around a given afk spot for mob farms etc. to light up all the caves. I guess thats a bit hard to implement though, since it would involve something similar to the TSP but just in case someone starts working on this, maybe they got a good idea to implement this cheaply too

[AlpineBoi]

I've been wanting a similar feature. What I've done this far is I've used the #thisway 12 and #path commands to get to the next point where a torch needs to be placed, after finishing the row I went to the next point in the new row manually. An illumination feature starting in the corner of a selected area and placing a torch every n amount of blocks would already do wonders.

[ninonook1]

shame this feature hasnt been added yet, it would be great for my slime chunks so that i don't have to go through the hassle of lighting up all the caves

[figloalds]

I know this is beating a dead dog, but I thought to myself: "Ima build a schematic with the torch placements in it, then build repeating, in this way, Baritone will make a tunnel with torches in the way that I want" But what happens is, it sees "minecraft:wall_torch" in the schematics and you can't have this item in your inventory; So if you say #buildSubstitutes wall_torch->torch then what it does is break any torches placed on that wall and then gets stuck I tried using buildValidSubstitutes but it seemed to completely ignore it, stop and tell me I don't have any "wall_torch"

I understand this conflicts with minecraft quirks, the bot assumes that the blocks you place and the blocks you have in your inventory always have the same ID, but that's not always the case

[ZacSharp]

You seem to have some false understandings and the last sentence is plain wrong so I feel like I have to explain some things.

Lengthy off topic explanation

First and foremost, items and blocks are not the same thing. Some items tend to be closely related to some block, but they are still different things just like different currencies are not the same even though you can convert your money back and forth. The second, less important, thing is that when people (including me) talk about "items" they mean a mix of `Item` and `ItemStack` with the former being the thing which uniquely corresponds to an item ID and the latter being an `Item` together with a count and optional NBT data. Similarly "blocks" come as `Block` with a unique mapping to and from block IDs and as `BlockState`, which is a `Block` together with values for its block properties. These two distinctions usually aren't too important (unless you are writing code) but they do mean that block/item IDs don't directly correspond to the things you usually call block/item and they also play into how Baritones settings work. Both `buildSubstitutes` and `buildValidSubstitutes` map `Block`s to `Block`s so when you set `buildSubstitutes` to `wall_torch->torch` you werent't telling Baritone to use the item with id `minecraft:torch` to place blocks with id `minecraft:wall_torch`, you were telling it to place standing torches instead of wall torches. If you set `buildValidSubstitutes` to `wall_torch->torch` Baritone will still try to put the torches on the wall but if one of them happens to be standing already it won't bother changing that.

> the bot assumes that the blocks you place and the blocks you have in your inventory always have the same ID This is the part you should completely forget. Baritone does not make that assumption and it will fail for exactly the same reason when building basically any other directional block, which usually use one block for all directions. The reason is that to get an estimate of what it can place Baritone iterates over all items in its inventory and if applicable asks Minecraft what would be placed if it were to look straight down and use that item right now at its current position to place a block. For torches that's their floor variant so Baritone ends up thinking it can't place wall torches. If you walk closer enough to the position where it has to place you will notice that it will place the "unplaceable" wall torch. That is because if a position with a missing block is in range Baritone will do the same check but with rotations to look at a neighboring block so now the result is the block state that would actually be placed (barring some particularly annoying cases, of course). The reason why it works like that is that that's (probably, disproofs welcome) the best you can get without brute force reimplementing a bunch of Minecraft logic (leijurvs plan for builder-2) or doing some smart automated trial-and-error. Minecraft placing logic is arbitrary code so 100% correct and complete automated analysis is in fact [impossible](https://en.wikipedia.org/wiki/Halting_problem).

[ZacSharp]

Though about this another time and remembered why this is not as simple as having BuilderProcess place some torches at positions determined on the fly. Schematics are inherently local and while it is currently possible to have a schematic change when the world changes at its initial position (breaks with buildRepeat) that would be very bad design and would easily break when improving BuilderProcess (or prevent the improvements). If we want to use BuilderProcess to place the torches then all positions have to be computed up front, probably by calculating hypothetical light levels ourselves, or we need an entire new process.

[PlasmaHH]

Can't use WorldEdit because I'm not op. Can't use MCEdit because that project died 3 years ago.

I think the best thing I can personally do is to use a world-downloader mod to download the multiplayer world, host a local 1.16.5 server with the downloaded world and connect to it using MC 1.8.9 with via-version with another world downloader (the most popular one requiring you to find a download of java 6, as it does not work on later versions of java), then up in mcedit and run this autotorch script someone happened to have made over six years ago, then remove all blocks except the torches, then convert the final world as a .schematic file, then use litematica to preview the blocks back in the multiplayer world and line them up, then have baritone .build the torch schematic.

That, or take some java classes and learn how to make baritone "walk to nearest dark spot and place a torch". T~T

If anyone wants to go that route, it can be made significantly simpler to generate the litematica with the torches by using carpet mod and some script ( https://github.com/gnembon/scarpet/blob/master/programs/survival/auto_lighter.sc )

[Paladynee]

it's been 4 years and this has not been implemented yet. this is NOT a niche application nor should it be hard to implement. the only hard part i can think of is finding suitable places for the torches to be placed. it's no different than a mine command except the targets are not to be mined but instead placed torches, and the targets are blocks where torches can be placed and the light level is >=7. if a block is left under 7 lightness, adjacent blocks can be checked recursively for placement candidates. then the pathfinder can take care of the rest. you probably dont even need to precalculate all the placement candidates in the first place. i dont understand why everyone is beating around the bush? i wish i knew how to write java to help out with this.

[PlasmaHH]

it's been 4 years and this has not been implemented yet. this is NOT a niche application nor should it be hard to implement. the only hard part i can think of is finding suitable places for the torches to be placed. it's no different than a mine command except the targets are not to be mined but instead placed torches, and the targets are blocks where torches can be placed and the light level is >=7. if a block is left under 7 lightness, adjacent blocks can be checked recursively for placement candidates. then the pathfinder can take care of the rest. you probably dont even need to precalculate all the placement candidates in the first place. i dont understand why everyone is beating around the bush? i wish i knew how to write java to help out with this.

Chances are people have lives and don't work full time on this...

[SeasonalFerret]

i wish i knew how to write java to help out with this.

Everyone wishes for this to be added, and yet no one is willing to take the time to learn.

Considering the lack of interest from anyone capable of creating this feature, I would be fine with closing this as being stale. I believe enough has been said for anyone with genuine interest to work on this, so the only acceptable resolution to this issue is either a PR in the future or simply letting this idea to die in obscurity, and not just complaining that no one will do it. I'm tired of getting yearly emails about this thread and it's just people begging.

[PlasmaHH]

i wish i knew how to write java to help out with this.

Everyone wishes for this to be added, and yet no one is willing to take the time to learn.

Considering the lack of interest from anyone capable of creating this feature, I would be fine with closing this as being stale. I believe enough has been said for anyone with genuine interest to work on this, so the only acceptable resolution to this issue is either a PR in the future or simply letting this idea to die in obscurity, and not just complaining that no one will do it. I'm tired of getting yearly emails about this thread and it's just people begging.

Can't you just unsubscribe? I get that all begging and complaining is totally pointless and a waste of time, but I generally don't like the idea of just closing stuff if its stale in any project, you never know if someone will one day come along and searches for features to implement... they will surely not sift through closed issues... also who knows, maybe in a couple of years we can ask some AI to just solve all the tickets for us ;)

[Paladynee]

you want me to learn java instead of "begging"? fine. see you in a few months.