VoxBreaker | An OOP Voxel Destruction module

Resources Community Resources
, , ,
#41

he (Dev of Jujutsu Shenanigans) modified and optimized another voxel destruction module, Vex, to the point he stated it wasn’t even like the original module anymore

3 Likes
#42

That is actually the module I used as a basis here as well, but for reasons I’ve stated in previous posts, Vex is incredibly unoptimized and not really fit for the purposes I had intended on using this module for. Interesting though.

3 Likes
#43

UPDATE

  • Module should now work perfectly on both the server and client.

  • Added functionality so that module will make textures, surface GUIs, and decals on parts invisible until voxels reset.

  • Fixed a bug where the .Touched() event would fire for parts that have already been touched. Now, the .Touched() event will only fire when new voxels are touched.

  • Added a :Start() function and :Destroy() function to moveable hitboxes. Now, hitboxes must be called with :Start() in order to activate. And :Destroy() must be called to fully destroy the hitbox. And because of this, you can now pause and resume the hitbox whenever you’d like. Also, if you don’t want to call :Start(), I’ve added a toggle in the settings which makes moveable hitboxes start automatically without having to call :Start().

Added new example tool to test place:

test place has been updated
will be setting up github repository later

If anyone is still having any issues with the module, please let me know,

2 Likes
#44

Also, I’m working on implementing the module into my own games, and it seems to be working on the server without issues:


(The debris are made on the client using remote events, the actual voxels on the server are destroyed)

So if you run into issues on the server, it is likely because you are using larger destruction, which may cause some performance issues.

6 Likes
#45

can you explain the process? Like when you knockback a person do you create a normal or movable hitbox and etc, i’m trying to use this module for my game but i’m not sure on how to go on about it.

edit: i figured out how to create the debris on the client while deleting it on the server but i’m still wondering which hitbox you used for knockback impacts

1 Like
#46

Hi im still having the issue with the server not having it work properly its likely me doing something incorrectly in the video I showed whats happening and I do have the newest version of the module

here the part of the code that uses the module

                    local VoxBreaker = require(game.ReplicatedStorage.VoxBreaker)
					local Size = Vector3.new(10,10,10)
					local Cframe = humRp.CFrame
					local Shape = Enum.PartType.Ball
					local MinimumSize = 5
					local Seconds = 5

					local Voxels = VoxBreaker:CreateHitbox(Size,Cframe,Shape,MinimumSize,Seconds)
					for i, v in pairs(Voxels) do
						v:Destroy()
					end
3 Likes
#47

So it kind of depends on your use case. If you want to blast someone through multiple walls like in the videos i shared, then heres how you would do it:

-Create a moveable hitbox (i did so on the server)
-Then, using a while loop, make the hitbox move with the targets velocity:


local moveable = voxBreaker.CreateMoveableHitbox(3,20,Vector3.new(5,5,5),CFrame.new(),Enum.PartType.Ball)
moveable:Start()
local connection
local touched = {}
connection = moveable.Touched:Connect(function(Parts)




	for i,v:Part in pairs(Parts) do
		v.Parent = script
	end

	Remote:FireAllClients(Parts,Character.Instance.HumanoidRootPart.Velocity/2)

	for i,v:Part in pairs(Parts) do
		if table.find(touched,v) == nil then
			v:Destroy()
			table.insert(touched,v)
		end
	end
end)

while true do
	moveable.Part.Position = Character.HumanoidRootPart.Position + Character.HumanoidRootPart.Velocity / 12 
	task.wait()
end

Then you can disable the hitbox whenever you’d like. Visually, it looks like this:

7 Likes
#48

So if you could turn the visualizer on in your module settings, that would help, as I don’t really know why it’s not working for you here. I’m using the same script and it works just fine:

3 Likes
#49


sorry for the cropped video had to do that to fit the file size limit

2 Likes
#50

Here’s an example rbxl file, that uses basically the same code.
vb.rbxl (65.0 KB)

Try to compare it with your own code, and see if that helps

4 Likes
#51

I figured out the issue was nothing to do with scripts and that it was just the part not being anchored

3 Likes
#52

Thank god for this, you’ve saved me weeks of pain and misery. Now I can make a proper destructible map for my game.

3 Likes
#53

Do you ever think you will make it so the part debris will be a built-in feature for the module? Like as a parameter whenever using the module?

2 Likes
#54

So, in the example you are asking about, I’m creating the voxels on the server and then cloning them on the client. My intention was to have something that can work either on the server or the client, and then you can choose to use remote events and the like to transfer data about the voxels between the server and client. Now, incorporating that functionality into the module wouldn’t be super difficult, but I would like to keep the module simple enough to where you have full control over the client-server interactions. And really, doing that isn’t super difficult. Just fire a table to the client containing all the voxels and just loop through it to clone them. If more people ask though I might consider it.

#55

Would it possible to remove attributes from this system and use instead metatables, or tags to store data better? Or simply implement support for raycast params. I might implement it myself if i have time tho.

#56

Metatables would probably be the best way to go. I was considering using them when making the module, but I decided to go the easy route and use attributes. And im not super familiar with tags, but I dont believe tags can store values tied to specific keys. The reason I use attributes is because they allow me to change the boolean value of “Destroyable” to true or false, to disable voxels from being divided further. Now I could probably make it work with tags but attributes were just the easiest option for me. In a future build ill probably migrate to metatables.

Admitedly there is likely some redundancy in the code. In order to include the functionality to reset voxels after a certain time period, I had to mess around quite a bit with the module in order to achieve that. And I did it in a pretty roundabout way so honestly you could probably question the effiency of certain parts of the module.

And what would raycast params contribute? The module uses workspace:GetPartsInPart() to detect parts. Unless you meant overlap params.

2 Likes
#57

My bad, idk why i also said tags. Anyways, i meant to use raycast params to identify the parts that can be voxelized or not. This would allow user to blacklist, or whitelist certain instances with ease it would be probably better and cleaner than attributes. I actually did a similiar resource a year ago but its extremely outdated and probably not working anymore

2 Likes
#58

can you explain how youre going about this

1 Like
#59

Well I thought it was pretty self-explanatory, but like I said, it is relatively simple. Just fire a remote event to the client for every .Touched() event of the hitbox, and pass the table of voxels through the remote. Then on the client you can destroy the parts, unanchor them, move them with bodyMovers and such, etc.

1 Like
#60

im getting this problem where the voxel table im firing to the client is just empty

2 Likes