Dynamite! #1309
Dynamite! #1309
Conversation
|
|
Ray based explosions
|
|
|
The dynamite block model is clever, but it stops you from making a giant pile of dynamite (without there being a bunch of gaps). I think a standard cube would be fine: |
|
Question: would a pile of dynamite increase its range, or its power? |
New dynamite textures, remove dynamite block model
|
Both, preferably as emergent behavior. I would prefer to avoid dynamite blocks flying around like in minecraft tho. With #1261 we can make dynamite explosion damage blocks it can not break, so consecutive explosions would break blocks damaged by previous ones. As for range, I would like to count how many TNT blocks are touching and merge their explosion strength and range as an optimization. That said current tag based system (
|
|
Resolved conflicts with network refactor. |
Argmaster
force-pushed
the
feature/dynamite
branch
from
c768923 to
8158a14
Compare
IntegratedQuantum
left a comment
IntegratedQuantum
left a comment
There was a problem hiding this comment.
preliminary review, I haven't looked at the actual explosion logic yet.
| @@ -0,0 +1,12 @@ | |||
| .{ | |||
| .tags = .{.canBeIgnited, .explosionMedium}, | |||
There was a problem hiding this comment.
Shouldn't the explosion radius be specifiable as a separate property or something? I'm sure we can spare a u8 per block type for that.
There was a problem hiding this comment.
That is wasteful and not a sustainable model. This property will be used by 2 blocks in base game (maybe 5 if you let us be creative). And it is completely irrelevant to performance. Will you add a field for every property that makes sense for 3 blocks? And what if a modification wants to add one of those? Instead we could have a sparse set of hash maps string to zon and just solve that problem in generic way.
There was a problem hiding this comment.
Well, I think it's only a matter of time until addon creators want to make nuclear explosions with this.
Either way this can be done in the future if you want.
Do some of the changes quantum asked for
apply formatting fix
|
Damage for stone and mud
|
|
Future improvements:
|
| defer main.stackAllocator.free(name); | ||
| textInput = TextInput.init(.{0, 0}, 128, 22, name, .{.callback = &createWorld}, .{}); | ||
|
|
||
| const widgetWidth = 160; |
There was a problem hiding this comment.
We call them components, not widgets
| if(!main.server.world.?.allowExplosives) return; | ||
| doExplode(pos); | ||
| } | ||
| fn doExplode(pos: Vec3i) void { |
There was a problem hiding this comment.
I do not believe this belongs in the network code. Maybe the server world would be a more appropiate place?
There was a problem hiding this comment.
Honestly I think they should be block entities and this code should be inside / next to onInteract, tho it is a big change and big redesign. This also would mean we are back to believing whatever client says, unless we introduce server side onInteract.
IMO we should consider it though because it would be an example of block entity with such interaction and some attached metadata (explosion radius).
There was a problem hiding this comment.
Well, you could just propagate it as a block entity data change, then you can check on the server side, if the gamerule is set.
Implementing it as a state change could also allow adding a short delay and some fuse particles before detonating.
|
Closing until it's a priority to integrate similar stuff into engine. |
5 participants
Description
This pull request introduces sulfur based explosives:
Dynamite stick is crafted from 2 sulfur and 2 coal
It can be placed like torch and can be ignited with torch. Explosion is instant and does not harm player.
Dynamite block can be crafted with 16 dynamite sticks
It has significantly higher block damage and damage radius
Explosions are done with ray casting and take resistance and health of block they break into account to reduce the radius of the explosion. Blocks marked as air and fluid are not destroyed.
Links
Depends on: #1313
Related to: #849