VoxBreaker | An OOP Voxel Destruction module

Go ahead, would help me better visualize it

this might be little hard since they changed the game a bit

robloxapp-20240709-1805281.wmv (3.5 MB)
its a very blurry , I don’t want the wall I built to reset itself like the wall i destroyed that reseted @Bartokens

I’m even more confused now. What exactly are you trying to achieve? From everything you’ve told me it just sounds like you want a way for your parts to not reset, which is already in the module

now i kinda feel stupid, the built structure cant reset but the map can

Is this what you’re saying, I have a building system in my game. I don’t want anything created by the building system to be destroyed. Is this what you’re saying? If this is what you’re saying, just don’t give “Destroyable” attribute to built blocks.

Edit : I understand what you’re saying now. You want the built barricades to be able to be destroyed, but not regenerate. If that is the case, you can use 2 seperate modules of VoxBreaker, one for the barricades, and one for the normal buildings. The barricade module should be looking for a different attribute, and the reset time should be -1. The other module can remain the same.

for some reason -1 breaks my game which i hate

might be a bug. I’ll be updating the module in a day or two.

yeah thats what i meant the edit part

also can u do anything about the lag that happens everytime the voxel destructon first happens or is that just a me problem

1 Like

theres a bug where if you break a part with a materialvariant the voxels and the destroyed part will be reset to the default material without the variant

for some reason it says “attempt to compare table < number” any idea how to fix?

local collectionservice = game:GetService("CollectionService")
local damage = script.Parent.Configuration.Damage.Value
local Attack =nil
local attacking = false
local voxel = require(game.ServerStorage.VoxBreaker)
local editeddamage = damage
local debris = game:GetService("Debris")
local hitbox = voxel:CreateMoveableHitbox(0,script.Parent.Sword.ChopPoints.Size,script.Parent.Sword.ChopPoints.CFrame,Enum.PartType.Block)
script.Parent.Activated:Connect(function()
	attacking = true
	local moveDirection = script.Parent.Parent.HumanoidRootPart.CFrame:VectorToObjectSpace(script.Parent.Parent.Humanoid.MoveDirection)

	if moveDirection.X > 0.2 then
		Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.AttackRight)
		print("left")
	elseif moveDirection.X < -0.2 then
		Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.AttackLeft)
		print("right")
	else
		Attack = script.Parent.Parent.Humanoid:LoadAnimation(script.Parent.Animations.Attack)
	end

	hitbox:Start()
	hitbox:WeldTo(script.Parent.Sword.ChopPoints)
	 Attack:Play(0.1,3,0.7)
		script.Parent.Handle.Swing:Play()
	Attack.Ended:Wait()
	attacking = false
	hitbox:Stop()
end)

hitbox.Touched:Connect(function(part)

end)

Thats another bug. Sorry for the update delays ive been a bit busy

3 Likes

that’s fine, i havent had any other problems with the module and this was just a minor one

how can i make a hitbox that enables from knockback performant
i made it so whenever somebody gets ragdolled usually from knockback it starts doing raycasts in the direction of movement
and if it finds a result it places a hitbox there but it makes my frames drop like crazy so idk how to improve it

Im expriencing a bug where sometimes the part thats being destroyed flashes

UPDATE

Features

Bug Fixes

  • Fixed material variants and surface types not being applied to voxels.

  • Made voxel resetting nearly seemless. The parts flashing should be less noticeable now.

  • Fixed setting reset time below zero not working. Setting reset times to below zero now makes it so that voxels will just never reset.

  • Various small logic changes for better optimization

Other

  • There is still one bug that I for the life of me cannot figure out. Mentioned in this post, for some unexplicable reason, voxels that are way bigger than they should be are being returned. The reason why I’m having trouble with it is because this only occurs when firing parts to the client. When I print out the part sizes on the server, they all appear the same size, but when fired to the client, some parts may be expanded for some unknown reason. This issue only happens when partcache is enabled, and I will be continuing to look for a fix.

  • New division algorithm will be coming in the next update. I didn’t include it here as it would be a pretty large change and I’m pretty short on time for this module.

  • I’m looking for ways to fix the brief flash that sometimes occurs when you initially voxelize a part. As you can see here.. I’ve tried making the original part have a slight delay before becoming transparent, but that results in some pretty ugly looking delay when breaking parts which makes the module feel laggy. And if I make the delay too short, then it just doesn’t work to fix the flash. If anyone has any ideas for fixes, do lmk.

Github Repo and Test Place have been updated to support the new version

2 Likes

Amazing Update!!!, Ive been waiting patiently :smiley:

1 Like

Seems like parts are a little inconsistent when breaking now

Here the parts are much thinner than they should be when broken
image
Here the parts are much bigger than they should be
image
combination of both
image
Its very performant though now
image
sometimes it just ignores minimum part size
I think it might be the same bug you were talking about with fireallclients
I solved most of this by turning part cache off but minimum size still seems to be off, even without part cache this module runs extremely well.

I completely fixed this by doing this in the DivideBlock() function:
image

there is pretty much zero delay and the flashing disappears completely.