I'm trying to make torches and wall torches not generate any light in my custom dimension

To do that I use reflection to access the lightLevel parameter inside BlockState

 

var BlockState.lightLevelKt : Int by ReflectField("field_215708_d", true)

 

I then made a function to change the value for all possible BlockStates in a block, or reset it to default if no argument is passed

 

fun Block.overrideLightValue(value: Int? = null) = stateContainer.validStates.forEach {it.lightLevelKt = value ?: getLightValue(it)}

 

I then use the WorldEvent.Load event to change the lightLevel accordingly

 

@SubscribeEvent
fun onWorldLoad(event: WorldEvent.Load) = event.runClient {
    if (world.dimension.type.id == Glacia.DIMENSION.dimensionType.id) {
        Blocks.TORCH.overrideLightValue(0)
        Blocks.WALL_TORCH.overrideLightValue(0)
    }
    else {
        Blocks.TORCH.overrideLightValue()
        Blocks.WALL_TORCH.overrideLightValue()
    }
}

 

But I can see how this approach could conflict with any other mod using the same approach (even though it's kind of unlikely that two installed mods do this) as they would reset each other's lightValues

Any ideas?

I would create my own version of torch that does not emit light (possibly naming it "unlit torch" to notify the player) and replace any placed torch block with my custom one.

26 minutes ago, DavidM said:

I would create my own version of torch that does not emit light (possibly naming it "unlit torch" to notify the player) and replace any placed torch block with my custom one.

That might be a good solution; is there any event that's fired when a block is placed even if it wasn't placed by an entity? (eg. an explosion starts a fire, but I don't want fire to spawn)

Edited April 19, 20205 yr by Alex Sim

The closest you can get to whenever a block is changed is BlockEvent#NeighborNotifyEvent. One thing of note is that this is executed solely on the logical server.

1 hour ago, ChampionAsh5357 said:

The closest you can get to whenever a block is changed is BlockEvent#NeighborNotifyEvent. One thing of note is that this is executed solely on the logical server.

For some reason I get a terrible lag the moment I use world.setBlockState inside NeighborNotifyEvent, what would be the best "flags" argument to use in setBlockState

9 hours ago, Alex Sim said:

For some reason I get a terrible lag the moment I use world.setBlockState inside NeighborNotifyEvent

That would make sense as calling that method results in a cyclical process. The issue with this method is that you're calling the event and injecting your method before the previous one is even done. Visually, it executes: First Block Placement -> Event at neighbor check -> Second Block Placement -> Event at neighbor check (potential for infinite loop) -> Finish Second Block Placement ->  Finish First Block Placement. As for the flag, since it is only executed on the server, you must have the two least significant bits enabled. Another one that may help reduce lag is that if you are okay with no neighbors being affected is to add 16.

 

If you want a list of flags:

1 will cause a block update.

2 will send the change to clients.
4 will prevent the block from being re-rendered.
8 will force any re-renders to run on the main thread instead
16 will prevent neighbor reactions (e.g. fences connecting, observers pulsing).
32 will prevent neighbor reactions from spawning drops.
64 will signify the block is being moved.

 

I would recommend 1, 2, and 16 = 19. 16 shouldn't be checked however if you want an unlit torch to have a different value on redstone or use it for observer input. Technically this is not a good way to execute code since you're basically injecting a method within itself, but it's the only event I can think of that does the job in all scenarios.

 

My confusion is that why do you need to check for all possible scenarios in your custom dimension? Entities are the only thing that can place torches, and structures can just redone to have unlit torches in them. It seems strange to me why you need it for every possible instance.

21 minutes ago, ChampionAsh5357 said:

That would make sense as calling that method results in a cyclical process. The issue with this method is that you're calling the event and injecting your method before the previous one is even done. Visually, it executes: First Block Placement -> Event at neighbor check -> Second Block Placement -> Event at neighbor check (potential for infinite loop) -> Finish Second Block Placement ->  Finish First Block Placement. As for the flag, since it is only executed on the server, you must have the two least significant bits enabled. Another one that may help reduce lag is that if you are okay with no neighbors being affected is to add 16.

 

If you want a list of flags:

1 will cause a block update.

2 will send the change to clients.
4 will prevent the block from being re-rendered.
8 will force any re-renders to run on the main thread instead
16 will prevent neighbor reactions (e.g. fences connecting, observers pulsing).
32 will prevent neighbor reactions from spawning drops.
64 will signify the block is being moved.

 

I would recommend 1, 2, and 16 = 19. 16 shouldn't be checked however if you want an unlit torch to have a different value on redstone or use it for observer input. Technically this is not a good way to execute code since you're basically injecting a method within itself, but it's the only event I can think of that does the job in all scenarios.

 

My confusion is that why do you need to check for all possible scenarios in your custom dimension? Entities are the only thing that can place torches, and structures can just redone to have unlit torches in them. It seems strange to me why you need it for every possible instance.

As I wrote above, I'm doing this for torches AND fire. I can just use the entity placement event for torches but not for fire (explosions, flint and steel, lava...)

39 minutes ago, Alex Sim said:

As I wrote above, I'm doing this for torches AND fire. I can just use the entity placement event for torches but not for fire (explosions, flint and steel, lava...)

As yes sorry. However, technically everything but explosions can be handled by the entity place item event and custom generation assuming you decide to create a new block for lava. Explosions can then be handled by cancelling the initial and then spawning another with everything but the fire flag checked false. That might have a greater reduction in lag if there still is a noticeable amount.