Jump to content

[1.15.2] Making torches not work in custom dimension (my take + any better solution?)


Recommended Posts

Posted

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?

Posted

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.

Some tips:

Spoiler

Modder Support:

Spoiler

1. Do not follow tutorials on YouTube, especially TechnoVision (previously called Loremaster) and HarryTalks, due to their promotion of bad practice and usage of outdated code.

2. Always post your code.

3. Never copy and paste code. You won't learn anything from doing that.

4. 

Quote

Programming via Eclipse's hotfixes will get you nowhere

5. Learn to use your IDE, especially the debugger.

6.

Quote

The "picture that's worth 1000 words" only works if there's an obvious problem or a freehand red circle around it.

Support & Bug Reports:

Spoiler

1. Read the EAQ before asking for help. Remember to provide the appropriate log(s).

2. Versions below 1.11 are no longer supported due to their age. Update to a modern version of Minecraft to receive support.

 

 

Posted (edited)
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 by Alex Sim
Posted
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

Posted
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.

Posted
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...)

Posted
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.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.