Create a checkSupportBlocks block update callback for torch decay instead of handling it through the rotation mode#2459
Conversation
…rough the rotation mode
| newBlock.data = @as(u5, @bitCast(data)); | ||
| if(newBlock.data == 0) newBlock.typ = 0; | ||
| } else { | ||
| std.log.err("Expected {s} to have cubyz:decayable or cubyz:branch as rotation", .{params.block.id()}); |
There was a problem hiding this comment.
This is not acceptable IMO.
This shouldn't be hardcoded.
This behavior is specific to a rotation mode, so it should call into rotation mode and determine output data there.
| .absorbedLight = 0x010101, | ||
| .collide = false, | ||
| .rotation = "cubyz:torch", | ||
| .onUpdate = .{ |
There was a problem hiding this comment.
Do you intend to add support requirement to foliage of all sorts?
There was a problem hiding this comment.
Yes, I think that's reasonable. For now I'm just preserving status quo though, by giving all torch-rotated blocks this property.
|
|
||
| var newBlock: Block = params.block; | ||
|
|
||
| if(params.block.mode() == main.rotation.getByID("cubyz:torch")) { |
There was a problem hiding this comment.
I think this is a obvious VTable call material.
Otherwise you will have a wall of if statements for everything that require support checks.
After some thinking, I come to a conclusion that calling into rotation vtable, as I wanted at first, may not be a good idea, so I guess I will have to let it slide for now.
There was a problem hiding this comment.
The other reason I kept it outside the VTable is because mods can't put stuff into the VTable either.
It might be worth investigating the usage of a tagged union (with empty fields), which would allow anyone to add new functions to the interface implicitly using an inline switch with @hasDecl.
2 participants
I'm open for better name suggestions.
I considered merging this into the decay callback, but I think it makes more sense as a separate thing since it only looks at direct connections.
In the future this could be extended to include carpet and signs.
@careeoki should lanterns and signs break when their support block is broken?
this is a first step towards #2330 and already demonstrates that this makes it more flexible, since now the addon author can decide how a block behaves when neighbor blocks are broken, instead of depending on the rotation mode code.
fixes #1103